Having just spent way too many days debugging my SSL / https configuration, I thought I'd save many of you my headache. Note that there are two Drupal modules that handle this for most people. I, however, was not so lucky. I have suspicions why neither of those modules worked for me, but to really understand the issue requires more time than I'm willing to devote to the issue. The two modules are:
I must admit that the maintainer of Ubercart SSL is an active maintainer of his module, and did provide some very helpful advice to me. And his module is very lightweight, unlike the larger Secure Pages module. The Ubercart SSL module appears to be written as an alternative to Secure Pages, which is probably welcome in several circles.
Secure Pages is a somewhat comprehensive module, that may be too large for adequate maintenance - the maintainer of Secure Pages rarely responds to questions or bug reports. So, for Secure Pages, it either works or it does not; if not, you're out of luck... Unfortunately, I was unlucky, experiencing the following behavior with the site I was securing, and neither of these modules handled the situation for me:
-
When going an https page, Secure Pages gave me a page with no images, not broken image icons, but no images at all.
-
When going to an https page, Ubercart SSL gave me a page with the graphics, but a broken padlock signaling mixed secure and insecure items on the page. The insecure items were the image files... At this point, I stopped using Secure Pages and only focused my debugging on Ubercart SSL usage.
-
Additionally, I was noticing that under Ubercart SSL I was not leaving https. I was not going back to http when I wanted - which was any path that does not have "cart" in it...
After days of testing variations with Ubercart SSL and hooks provided by the module to specify the path components that trigger going into and out of https, I still could not get my cart pages to appear without broken padlocks... (My reasoning was that the images had paths pointing into the Ubercart module directories, for the credit card images and their related imagery. They were somehow getting served as http, even when on a cart page.) Then, thank gawd, my research began to uncover people who had given up on Secure Pages, did not know about Ubercart SSL, and were placing their solution for going into and out of https purely in their .htaccess file. Investigating, trying some, and more research finally got me what I needed:
This fine page provided the core of my working solution:
http://www.runssl.com/content/how-redirect-drupal-or-ubercart-ssl-connec...
# (.htaccess lines that begin with a '#' character are comments, by the way.)
# This first line is a condition that is true if the site in not currently using https:
RewriteCond %{HTTPS} !=on
# If the above evaluates to true, then do the following...
# which is test the query string for beginning with '/cart/,
# if that is true then rewrite the url as https:
RewriteRule ^/?(cart/) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# the above handles going into https fine...
# this tests for the site currently being in https:
RewriteCond %{HTTPS} !=off
# if the above is true, this tests for no query string (the home page)
# and takes us out of https, back to http:
RewriteRule ^$ http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
# Note that if the customer does not go directly to the home page after checkout,
# they are still in https, and will stay there until vising the home page.
# So this pair of lines is looking for a query string matching any of my site
# paths other than "/cart/" paths:
RewriteCond %{HTTPS} !=off
RewriteRule ^/?(login|user|node|hdr_) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
I hoped to figure out how to simply negate the regular expression used to go into https, but never got that working. I actually like this solution quite a bit, because it lies outside of Drupal - meaning no additional module processing, updating and whatnot should be needed.
Now, for your purposes, if you only want to secure your cart pages, you can copy with I have here, place that inside your .htaccess file right after the <ifModule mod_rewrite.c> directive and before any of the Drupal path rewriting logic. Then, you simply edit the last line, the one with "(login|user|node|hdr_)" in it, and replace the contents of my round brackets with the paths in your site you want to take your customers out of https and into http. Each path item is separated by a '|' (vertical bar) character, so in my example the path that take you out of https begins with one of the following: "login", "user", "node" or "hdr_". Note that I have a series of paths like "hdr_coverflow_panel" and "hdr_videos", and that last "hdr_" path component will capture all of those paths.
I hope you enjoy the fruits of my SSL / HTTPS research. :)
Comments
I authored Ubercart SSL and
I authored Ubercart SSL and this is a good alternative to both Secure Pages and Ubercart SSL. These 2 modules cover 80% of most servers, but some servers are just setup in a way that neither of these 2 modules will be able to function properly and those people will need to resort to .htaccess solutions. Thanx for the blog, it should be helpful for those that are unable to get my module (Ubercart SSL) to function properly.
Wow. Honestly, I had no idea
Wow. Honestly, I had no idea people were reading my articles.
Let's see here:
Stephanie: Look at that last RewriteRule line and make sure the contents of (catalog/*|node/*) reflect any non-home page locations on your site your visitors could go after leaving checkout.
Estefan: I don't know how to help you. More information maybe?
guest-comment: yes, this should work in a multi-lingual, multi-site configuration.
Maarten & grindflow: I had that exact issue, and it is what drove me to find this solution. Utimately I found that my SSL Certificate was not installed correctly, and once that was fixed this solution worked perfectly. I'm using the above today, and have been for nearly a year now. Note that it was not until after I'd exhausted every possible cause on my side that an expert I'd hired walked over everything and just said "It has to be at your host." It took that consultant a half hour of talking with my host's tech support and walking them through before they saw their error. That was money well spent!!
Post new comment