Secure Server DropIn

[ProgramSupportHub]

1) Script Title: Drop-in content box v2.0

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici.../dropinbox.htm

3) Describe problem: Script is in an included html file. Script loads with regular server and attempts to load again under the secure server (https) when a customer logs in or tries to complete a purchase, but has an ajax error. Is there anyway to tell it not to load under the secure server? or how do I fix the ajax error on the https.

[jscheuer1]

It's hard to say for certain without seeing the page. Even then it might be difficult. But here's what I would try:

First make sure all of the files are on and being fetched from the secure server. That includes the close image, scripts and css, as well as the file(s) fetched via AJAX for the content. This latter will probably need to be on both.

For the one file not on your server at all, use the https version. Change:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>

to:

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>

Then if you want to skip the script for the secure server, where you have this or something like it add the highlighted as shown top and bottom:

<script>
if(location.protocol.indexOf('https') < 0){
var dropinbox1=new dropincontentbox({
	source:['#dropbox', 'dropincontent.htm'], //#id of DIV to show if defined inline, or [#id, path_to_box_content_file] if defined in external file
	cssclass:'dropinbox standardshadow', //arbitrary class(es) to add to the drop in box to style it
	showduration:10 //disappear after x seconds?
})

var dropinbox2=new dropincontentbox({
	source:'#reminder', //#id of DIV to show if defined inline
	cssclass:'dropinbox dropinboxaltstyle drop-shadow lifted',
	fx:'easeInExpo', //alternate drop animation keyword
	pos:[-20, -20], //custom position of drop in box
	deferred:1 //show box 1 sec after page has loaded
})
}
</script>

The browser cache may need to be cleared and/or the page refreshed to see changes.

If you want more help, please include a link to the page on your site that contains the problematic code so we can check it out.

[ProgramSupportHub]

Thank you for your reply,

I actually have already tried https with all links.

I did try to add the code above to exclude the script from https but it still has the ajax error on https pages.

You can find the script in play here

http;//programsupporthub.com

once there click on the registration link at the top right of the page to go to a secure page for the error.

I really only want the script to load once per session regardless of http or https

[jscheuer1]

Well we'll get to that. The only error I'm getting is in IE:

SEC7111: HTTPS security is compromised by http://forms.aweber.com/form/displays.htm?id=zCwsbKxMrAwM
customer?xCmd=register&jssCart=c29c37a34bb4a17f18f2dda73dfbad5f

That happens to be 1x1 .gif which I assume is transparent because no matter how much I blow it up, I still cannot see it. I also assume because of the .htm extension that it's being generated on the server. And that because it's still a 1x1 .gif without the query string, that the query string is used on the server side for some other purpose - tracking perhaps? Or possibly verification.

This file needs to be hosted on the https server. And it looks like it's a part of the dropin (templates/default/includes/dropincontent.html). Not it exactly, a variant:

http://forms.aweber.com/form/displays.htm?id=jIyMnJws7KwsbA==

But since the dropin isn't currently getting executed or even imported on the https page, I checked the source code of the page. It's there in the right-menu division's form.

So, I'm not sure if we can display the dropin once per session regardless of http or https, but this display.htm file needs to be hosted on the secure server to avoid the error.

What we probably can do is display the dropin once pre session on http and once per session on https. The reason being that one or more browsers may balk at reading the insecure cookie from the secure page and visa versa.

But, as I say, let's fix this problem first.

And, I just realized aweber.com is a third party, so unless they provide https for this file, you will have to skip it at least on the https page(s), which means you may also have to skip whatever service(s) they're providing. There's a good chance that they do provide https though. It may or may not cost extra if they do.

Yet Later . . .

And I see that the newsletter form itself (both on the dropin and the one hard coded on the right-menu on the https page) submits via post to aweber.com and that URL is insecure http. So if you submit that form on the secure page you would likely get a warning then too.

[ProgramSupportHub]

ok I corrected the aweber server call.

Like you I get the IE error, actually I can't even get it to load in IE.

I did check another https page and it does not load or give an error when switching from http to https on other pages but one. Strange? The "registar" page is https and all is fine but the "Members Login" page gives an "Error Fetching Ajax Content" but only when clicked on immediately after the original http page load. If you go from a http to any other https page and then to the "Members Login" it doesn't give an error.

If you have any suggestions they are much appreciated, if not I might just live with it.

Thanks

Curtis

[jscheuer1]

Yeah. The problem on the members page with the alert is caused when you navigate to it as http. When you navigate to it as https, there's no alert.

That link is:

<a href="customer.php?xCmd=account">Members Login</a>

It should be:

<a href="https://programsupporthub.com/customer.php?xCmd=account">Members Login</a>

Get that taken care of and we can then decide what to do about the dropin on the https server. We may be able to coordinate it with the one on the http server so that one or the other is only shown once per session for a total of one and only one per browser session. At the very least, we should be able to have essentially two identical dropins, one on each server that only show once per session on each server for a total of at least one and no more than two views per browser session.

Oh, and about that newsletter form that submits to aweber:

<form method="post" class="af-form-wrapper" action="http://www.aweber.com/scripts/addlead.pl"  >

It can be:

<form method="post" class="af-form-wrapper" action="https://www.aweber.com/scripts/addlead.pl"  >

At least it looks like it can, because navigating to either without post data gives the same warning:

Email Address Is Not Valid

[ProgramSupportHub]

Ok. I believe I fixed the layout problem and I added the https to the right menu aweber image. I'm still getting the fetching error for ajax. Any suggestions? In forums its hard to relay appreciation with writing but I do appreciate your help and suggestions.

[jscheuer1]

Nope, it's still http. on the main page, the one at:

programsupporthub.com/

The link whose text is "Members Login" is still http. If I do a 'view source' in the browser, the source code reads:

<a href="customer.php?xCmd=account">Members Login</a>

It needs to read:

<a href="https://programsupporthub.com/customer.php?xCmd=account">Members Login</a>

You can tell right away on most browsers, the ones that show the link you are about to click on in a status bar or some other spot on or near the browser window. Hover that link, you will see it's still http.

[ProgramSupportHub]

ok. I see that now. For some reason I overlooked that in the previous messages. Sorry about that. All appears to be working fine now.

Thank you for your help.

[jscheuer1]

Great! Um, now that we've got that fixed. Is the drop in behaving the way you want it to?

If I remember correctly, it now will show once per browser session and only on the http server.

That's probably fine unless your users can remain logged in across browser sessions.

Just in case you don't know, a browser session lasts as long as the user's browser is open. Not open to your page, open to any page anywhere.

Once their browser is closed, can a user still be logged in to your site? Like could they then relaunch their browser, navigate directly to one of your secure pages and still be logged in?

If so, we may want to rethink this a little. If not, and most sites do not allow logins to persist across browser sessions, I think what you have now is good, perhaps even optimal.