Switching to 100% SSL (https) - Thoughts?

[Feznizzle]

Hi,

I'm about to encrypt *all* traffic on my site. I'm a tad worried, any suggestions to help this transition go smoothly would be appreciated!

To switch over, looks like all I have to do is update in each includes file:
BEFORE: define('HTTP_SERVER', 'http://www.YOUR_SHOP.com');
AFTER: define('HTTP_SERVER', 'https://www.YOUR_SHOP.com');

Something that worries me is the possibility of imbedded file references (to images, pdf's, etc) existing in places like Category or Product Description. Do I have to worry about that breaking things?

I could search the entire DB for any use of "http:www.YOUR_SHOP.com" and replace with nothing (making the ref URL relative). But is that necessary?

I dunno. What else should I watch out for?

Thanks!

EDIT: The site is a ZC154

[DrByte]

Yes you should do it.

Yes you might have some assets where you mistakenly specified a non-https way to access them, in which case you'll need to fix each one manually ... by either making them https specifically (after testing that that works), or by making them relative to your site root .... or even better, by making them protocol-agnostic by using // instead of http:// or https:// .

You can test "most" pages by going to the page in your browser, then manually change the URL to https and press Enter. Then see if the padlock disappears ... if it does then you've got insecure assets on that page, and you can View Source for that page in your browser to find the offending items ... (actually, using the browser's "console" in developer tools mode is faster because it usually lists which ones it can't load, as console errors).

[mc12345678]

The other thing not referenced is that it is suggested to do as above but with ENABLE_SSL as false.

[picandnix]

The other thing not referenced is that it is suggested to do as above but with ENABLE_SSL as false.

Could you please elaborate on the theory behind this please? Not debating or questioning the suggestion just wanted to understand why for my own education

[DrByte]

The other thing not referenced is that it is suggested to do as above but with ENABLE_SSL as false.

Could you please elaborate on the theory behind this please? Not debating or questioning the suggestion just wanted to understand why for my own education

He's referring to something I've posted elsewhere about this matter. The ENABLE_SSL switch causes session-regeneration, which assigns new zenids when going between HTTP_SERVER and HTTPS_SERVER URLs. But since you're making both the same, you can turn off the extra load caused by ENABLE_SSL and also bypass the needless setting of new cookies. One less point of failure, and less overhead, making the site faster.

[Feznizzle]

Ok, I'll switch ENABLE_SSL to false.

Out of curiosity, what happens to legacy links? They'll just automagically redirect, correct?

[mc12345678]

Ok, I'll switch ENABLE_SSL to false.

Out of curiosity, what happens to legacy links? They'll just automagically redirect, correct?

If you do nothing else, arrival at the site for most pages will occur using whatever method was entered on the "browser". Subsequent navigation will be by https:. If this is not considered acceptable, should speak with your host about how best to implement arriving at a page always with https:.

[Feznizzle]

Thanks for the advice!

I am planning to add the directives highlighted below (exactly as shown) to my htaccess:

## BEGIN CEON URI MAPPING REWRITE RULE

RewriteEngine On

# Force HTTPS use, provide 301 to Search Engine
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# Don't rewrite any URIs ending with a file extension (ending with .[xxxxx])
RewriteCond %{REQUEST_URI} !\.[a-z]{2,5}$ [NC]
# Don't rewrite any URIs for some, popular specific file format extensions,
# which are not covered by main file extension condition above
RewriteCond %{REQUEST_URI} !\.(mp3|mp4|h264)$ [NC]
# Don't rewrite any URIs for some specific file format extensions,
# which are not covered by main file extension condition above
# Uncomment the following line to apply this condition! (Remove the # at the start of the next line)
#RewriteCond %{REQUEST_URI} !\.(3gp|3g2|h261|h263|mj2|mjp2|mp4v|mpg4|m1v|m2v|m4u|f4v|m4v|3dml)$ [NC]
# Don't rewrite editors directory
RewriteCond %{REQUEST_URI} !^/editors/ [NC]
# Don't rewrite logs directory
RewriteCond %{REQUEST_URI} !^/logs/ [NC]
# Don't rewrite bmz_cache directory
RewriteCond %{REQUEST_URI} !^/bmz_cache/ [NC]
# Handle all other URIs using Zen Cart (its index.php)
RewriteRule .* index.php [QSA,L]

## END CEON URI MAPPING REWRITE RULE

Did I do that correctly? Will my addition conflict with the CEON URI directives in any way?

MC, you said:

If you do nothing else, arrival at the site for most pages will occur using whatever method was entered on the "browser". Subsequent navigation will be by https:. If this is not considered acceptable, should speak with your host about how best to implement arriving at a page always with https:.

In looking at the highlighted htaccess directives above... will that accomplish what you suggest the host might be able to do for me?

[mc12345678]

Thanks for the advice!

I am planning to add the directives highlighted below (exactly as shown) to my htaccess:


Did I do that correctly? Will my addition conflict with the CEON URI directives in any way?

MC, you said:


In looking at the highlighted htaccess directives above... will that accomplish what you suggest the host might be able to do for me?

The highlighted code in the previous post looks like it would work to transition the user to https: with all of the remaining contents of the entered components. It will redirect and load again to then process the CEON uri portion ("bypassing" the first rule)

That said, the host may have a better solution based on their setup, which is why the recommendation to speak with them.

[Feznizzle]

By "better solution" are you referring to something like HSTS? Or HSTS preloading?

Also, by "better solution" are you implying that the code I referenced has drawbacks? The reload?

If reload is problematic, how can I get rid of it... but keep the 301?