Updated 21 April 2012 and 27 August 2012
Drupal Secure Pages module
http://drupal.org/project/securepages for 6.x-1.8 with D6.14 on 2009-10-03
updated for 6.x-1.9 with D6.22 on 2011-12-28
A dedicated IP and SSL Security Certificate installation are needed before enabling the module. There is a warning not to try it without these crucial prerequisites.
Make certain pages secure, specifying them as https.
When you want to make the entry and view of personal information or purchase information secure.
- Enable/disable again in its own admin section.
- Option: Switch back to http pages when there are no matches.
- Enter the: Non-secure Base URL
- Enter the: Secure Base URL
- Specify which pages will be secure: All except listed/only listed
- Specify ignored pages
This has been working. Problems have occurred after server upgrades, Drupal core upgrades, secure pages upgrades as well after upgrading contributed modules "Admin menu" and Übercart. For errors and possible solutions see further below.
Complete settings that work with Ubercart and Admin menu modules:
This puts the shopping cart, user interaction and admin section into SSL /https.
Complete ignore pages:
But there are many different needs and opinions.
On which pages to use?
Of course it depends on the site:
- User pages should be encrypted: User login, registration and lost password pages, where the user enters username and login password.
- Admin section: maybe not really needed for a normal site. There's nothing really there that is sensitive data, as far as I'm concerned.
- Node changes: maybe also not needed for a normal site that does not contain sensitive data. If the data is sensitive, then yes, including the admin section.
- Shopping cart should be fully encrypted: cart, checkout, confirmation, payment, payment gateway connection, order forms, customers and order summaries. The product catalogue is not encrypted.
Details for the list above
SSL node adding and editing:
SSL user interaction:
SSL complete admin section access:
SSL Ubercart's cart and checkout:
Other source has a long list:
Add more to Ignore pages (may not be needed, not included above):
Source: not noted.
Administration menu in SSL
For contributed module Administration menu, need to add (as included above):
Partially encrypted pages
Partial encryption will cause the browser padlock to disappear or give a warning - not good. This is a major headache. After fixing things, the issue may return when modules are updated.
When disabling JS optimization in admin > site configuration > performance, Ubercart's shopping cart block creates a JS error that results in partially encrypted pages. To fix it, re-enable JS optimization.
Some module's images may have incorrect permissions, generating behind the scenes errors (403 and 404 page not found), disallowing them from showing up in SSL, and finally causing "partial encryption" horror.
These can be identified with firebug, or browsers that will show missing images more clearly (chrome). Specifically:
- cart arrows in uc_cart with permission 640 can't show in ssl, change to 644 (this may have been fixed in newer UC version)
- paypal's included credit card images in uc_credit with permission 740 can't show in ssl, change to 644 (not fixed in current UC version)
Not sure why public images would have been assigned 640 or 740 permission. World users should have at least "read" = 4 a the end.
Other modules might generate different issues, but solutions may be similar.
Contributed module Admin menu not showing in SSL:
I fixed this issue, but unfortunately did not note it here. More in detail:
For a multilingual site using i18n, the contributed administration menu suddenly stopped working in SSL.On other sites on the same shared server, but not multilingual it is working fine.
With admin_menu module enabled and included for SSL, the page is trying to access:
This is NOT https, and results in 403 Forbidden (permission denied), or (lately) 503 Service unavailable. I guess this is enough for the admin menu not to appear. This despite js/* or any *js* combination specified in Ignore pages - as described in similar/SAME case http://drupal.org/node/498754.
Where is this cache? There are numbered js files in sites/default/files/js, but numbering does not correspond to the error. There is a cache_admin_menu table in the database. Emptying (not dropping) this table makes the admin menu appear! But only once. Any next page and the error is back (with the same cache number).
Clearing cache by performance menu, or specifically the administration menu cache by admin menu cache flush, does not clear this issue.
There's something related here, referring to cache, http, favicon:
Tried all the below for both the "partially encrypted" issue (now solved) and the administration menu not showing in SSL (not solved). Earlier I thought the issues are related, but solving the first without the second proves they are not:
Flushing all site and browser caches has no effect at any time.
Disabling the value for $base_url in settings.php has no effect.
The patch workaround has no effect.
Changing performance settings (cache, compression or optimisation) has no effect.
Source: http://www.missingubercartmanual.com/Configuring-Your-Site-For-HTTPS-whe... has an .htaccess suggestion, but uncertain to work on subdomain language sites. It also shows that if all else has been tried, it's possible that the SSL certificate was installed incorrectly (Post: Wow. Honestly, I had no idea...). More on .htaccess:
Other potential causes
Disabling and fully uninstalling both the secure pages and admin menu modules did not work either.
Tried the Übercart SSL module http://drupal.org/project/uc_ssl. Guess what, that either puts the entire site into SSL (always) or nothing. Not useful.
Finally I solved it through insertion of code, but I can't find either the code or the source now. I'll put it up as soon as I find it (my apolgies).
G is indexing https pages. I don't believe the entire site was ever SSL'd, except possibly during setup trial for a few minutes or so. And I initially thought it would not do that. But it has indexed one language page with https prefix. Very strange. It must be stopped from indexing any https. Need to look into this. WIP.
Note that I'm using subdomains (de.domain.com, nl.domain.com) for languages. These are *not* prefixes as defined in Site configuration > Languages > Configure. It's: Domain name only.
Security works on a per domain basis. This has implications for subdomains. It goes for SSL in general and also for the box secure pages module.
Subdomains based security would need to be set additionally:
I'll try multilingual variables (re i18n) to see if that will do it.
Found all seven secure pages variables in the variable database table. Actually I only want to specify the paths, they are: securepages_basepath (for the normal/http path) and securepages_basepath_ssl (for the ssl/https path). I think this might work (re i18n).
It's time to feed the fish in the pond.
I'm using only these two variables in order to avoid confused ssl settings among the languages. Inserted in settings.php multilingual variables: They work. Super.
The language switcher will not switch languages/domains while in ssl, but this is should probably be intended bahavior. Any user language switching will anyway be limited to the index page (if at all).
A dedicated IP is mandatory for all SSL, in general. A security certificate is needed for all SSL. Cpanel creation of certificate may appear to work, but might possibly be inactive (and will then require host support). Certificate site name must be exact (re: with/without www, or en, de, fr, nl subdomains), this is where the language domains issue comes in; I recall subdomain wildcard certificates as principally possible, but costly. At minimum the certificate can be self-signed (lots of browser warnings), that should be ok during site development phase.
Of course a good solution would be to switch from subdomain to prefix for all https pages... better to leave that alone.