Annoying SSL Refresh

The redirection from https to http via META tag was done as some users experienced problems under IE (warnings about insecure content, etc…). So I don’t think it’s good idea to perform redirect using headers. At least using the solution offered above.

What do you think about keeping secure connection after the first redirect?

[quote name=‘zeke’]The redirection from https to http via META tag was done as some users experienced problems under IE (warnings about insecure content, etc…). So I don’t think it’s good idea to perform redirect using headers. At least using the solution offered above.[/quote]



I suggest we dump IE6 support :mrgreen:

[quote name=‘zeke’]What do you think about keeping secure connection after the first redirect?[/QUOTE]



Hello Zeke,



The cart we were using prior to CS-Cart (.asp based) actually handled it just as you mention & this method worked very well !



Probably a good idea to include an admin panel setting so that store owners can select to use this method or not.

[quote name=‘zeke’]What do you think about keeping secure connection after the first redirect?[/QUOTE]



Personally, I don’t want to have a secure connection on any pages other than those that I require it (ie. login, create account, check out, etc.).

[quote name=‘adodric’]Personally, I don’t want to have a secure connection on any pages other than those that I require it (ie. login, create account, check out, etc.).[/QUOTE]



Hello Adodric,



What is your reasoning behind preferring users to switch back & forth between http / https when navigating thru the site?



I just found that it created a much smoother user experience when staying in https after the first request. Yes, there is a very negligable reduction in page load time, however, overall it is is much better than dealing with the lag times of switching back & forth between secure & non. :wink:

[quote name=‘Struck’]

What is your reasoning behind preferring users to switch back & forth between http / https when navigating thru the site?

[/QUOTE]



It’s mostly a personal preference. I just don’t feel like it is very professional to run an entire site under https.


[QUOTE]

Yes, there is a very negligable reduction in page load time, however, overall it is is much better than dealing with the lag times of switching back & forth between secure & non. ;)[/QUOTE]



The reduction in page time depends on a few factors and can vary drastically from one server to another. As for lag switching from http to https, the most drastic delay is the first time you load an https page, after that switching back and forth is not noticeable on my sites. I’d rather this delay be after a customer has decided to buy or create an account rather than on the first page load into the site, where I may lose them before they even start shopping. The initial page load into a site is important.

The problem isn’t going from http to https, [COLOR=“DarkRed”]the problem is going from https back to http.[/COLOR]

[quote name=‘ePlanetDesign’]The problem isn’t going from http to https, [COLOR=“DarkRed”]the problem is going from https back to http.[/COLOR][/QUOTE]



Yes, I wasn’t speaking in CS Cart terms. Just general terms. I’m going to keep the solution of using headers for the redirect. I’ve tested my site with as many browsers as I can find and I haven’t had any issues with it.

Adodric,


[QUOTE]I’d rather this delay be after a customer has decided to buy or create an account rather than on the first page load into the site, where I may lose them before they even start shopping. The initial page load into a site is important.[/QUOTE]



Site visitors would not enter your site in https mode, what Zeke is referring to is having the ability to stay in https mode after the initial call into https rather than switching back & forth, back & forth. Besides that, certainly doesn’t hurt for shoppers to feel the added warm fuzzies of seeing the secure padlock symbol acivated for longer periods of time.

Struck,



Yeah I saw that Zeke had said that. I just mis-read your post. I thought you were saying your old cart was always in https but you didn’t, I just mis-read it. I still prefer to not remain in https, just a personal preference really and honestly, the fix using headers seems to work just fine.



What I’d rather like to see is them making it so when I link is created it is created properly, either as http or https, not just defaulting all to one or the other based on the current pages secure status.

[QUOTE]I still prefer to not remain in https, just a personal preference really and honestly, the fix using headers seems to work just fine.[/QUOTE]



The header refresh fix was a major improvement, no doubt! However, I do hope that Zeke can offer the community a way to test out having the ability to remain in https after the initial call as it does create a very nice user experience, and that is what it is all about. I do believe alot of CS-Cart users would choose to operate their stores this way if given the option. I did suggest that Zeke allow this to be a selectable option if possible. :wink:

[quote name=‘Struck’]However, I do hope that Zeke can offer the community a way to test out having the ability to remain in https after the initial call as it does create a very nice user experience, and that is what it is all about.[/QUOTE]



This should be an easy change I believe. Should be just a few lines removed and maybe one added. If you want I’ll take a look at it later.



I’d also like to see them implement it so the links are created properly in the first place. That way no header redirects will be needed (the https and http should still be checked though just incase a customer puts in http on a https page, in that case a redirect would be used but that would be almost non-existent).

[quote name=‘adodric’]This should be an easy fix I believe. Should be just a few lines removed and maybe one added. If you want I’ll take a look at it later.



I’d also like to see them implement it so the links are created properly in the first place. That way no header redirects will be needed (the https and http should still be checked though just incase a customer puts in http on a https page, in that case a redirect would be used but that would be almost non-existent).[/QUOTE]



Well, if you can manage the time that would no doubt be appreciated by many!



I would be one of if not the first to start testing it out.



I am not a coder, but I can perform usability testing like there is no tommorrow! :smiley:

[QUOTE]

I’d also like to see them implement it so the links are created properly in the first place.

[/QUOTE]



Agreed!

[quote name=‘zeke’]What do you think about keeping secure connection after the first redirect?[/QUOTE]



That would be Ok unless there is a better way to redirect without using meta refresh, the mod in this thread works well and no problems on my end in all browsers that I have checked.

[quote name=‘Struck’]

I am not a coder, but I can perform usability testing like there is no tommorrow! :D[/QUOTE]



Ok Struck, here it is. I was going about this the hard way then found this code which was very simple. Test away, personally I don’t want this functionality but I hope it helps you if you do want it. I did test it some and the load times did seem longer making each page https (after the first https page visit), although I’m not currently running Smart Optimizer which should help.



In f.control.php find this code and comment it out or delete it (it is in the fn_dispatch function):



// if we are on https and the controller is insecure, redirect to http
if (!isset($secure_controllers[CONTROLLER]) && defined('HTTPS')) {
fn_redirect(Registry::get('config.http_location') . '/' . Registry::get('config.current_url'));
}




with it commented out:



// if we are on https and the controller is insecure, redirect to http
[COLOR="Red"]//[/COLOR]if (!isset($secure_controllers[CONTROLLER]) && defined('HTTPS')) {
[COLOR="Red"]//[/COLOR]fn_redirect(Registry::get('config.http_location') . '/' . Registry::get('config.current_url'));
[COLOR="Red"]//[/COLOR]}

Ok, we can add the option, something like “Stay on secure connection after first redirect”.



As for redirect from https to http using headers, we can do it, but I’m afraid we can broke redirects in some IE version.

[quote name=‘zeke’]Ok, we can add the option, something like “Stay on secure connection after first redirect”.



As for redirect from [COLOR=“Red”]https to http[/COLOR] using headers, we can do it, but I’m afraid we can broke redirects in some IE version.[/QUOTE]



The problem is http to https,



How about an option for that too?

[quote name=‘adodric’]Ok Struck, here it is. I was going about this the hard way then found this code which was very simple. Test away, personally I don’t want this functionality but I hope it helps you if you do want it. I did test it some and the load times did seem longer making each page https (after the first https page visit), although I’m not currently running Smart Optimizer which should help.



In f.control.php find this code and comment it out or delete it (it is in the fn_dispatch function):



// if we are on https and the controller is insecure, redirect to http
if (!isset($secure_controllers[CONTROLLER]) && defined('HTTPS')) {
fn_redirect(Registry::get('config.http_location') . '/' . Registry::get('config.current_url'));
}




with it commented out:



// if we are on https and the controller is insecure, redirect to http
[COLOR="Red"]//[/COLOR]if (!isset($secure_controllers[CONTROLLER]) && defined('HTTPS')) {
[COLOR="Red"]//[/COLOR]fn_redirect(Registry::get('config.http_location') . '/' . Registry::get('config.current_url'));
[COLOR="Red"]//[/COLOR]}
[/QUOTE]



Thanks a bunch for donating your valuable time to this Adodric, very much appreciated!



I just now got around to implementing this, and after 5 mins of testing it appears to be working very well! I am only noticing a very slight increase in page load times while navigating in https mode, and I stress very slight. This will be even less noticable after the cache has finished building the https pages in the smartoptimizer cache.



I will continue testing this code mod & report back on our results, good or bad, however, as mentioned it appears to be a very usable option as of right now. :wink:



PS: This is being tested on a live store!



Thanks again for your assistance!