You are here

Drupal secure pages module

Updated 4 September 2012. Created by janroe 12 October 2009.

Updated 21 April 2012 and 27 August 2012

Drupal Secure Pages module 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.

Main function

Make certain pages secure, specifying them as https.

Example function

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):


Source: and another indication at (Ubercart SSL, which I do not use). There does not appear to be any handbook documentation on this.


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.

JS Optimisation

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

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: 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 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*ogle Problem:

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.

Multilingual conversion:

Note that I'm using subdomains (, 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.

Standard set up is:
a single (1) standard base location, like:
a single (1) secure base location, like:

Subdomains based security would need to be set additionally:

a single (1) standard German base location, like:
a single (1) secure German base location, like:

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).

Background note:

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.


Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Thanks for your help in stopping spam.
Fill in the blank.