The 7.x dev release should be working for most uses. There are a few core bugs that are holding up a full release:

Steps to install

When these core issues are resolved, 7.0-1.0 will be released.


progress update - There is code in the DRUPAL-7--1 branch, along with some simpletests. Basic redirect functionality is working, although I haven't tested more complex use cases (overlay, non-clean URLs, subdirectory-install, locale module, aliases, etc ).

Overall 7.x support should be considered experimental at this point. Watch this issue for more updates...

Update - I've simplified some functions using drupal_parse_url(), and tweaked the way securepages interacts with cache_page in D7. Tests have been expanded a bit. A few core bugs have been uncovered.

The main focus now will be on overlay, path aliases, and passing tests (or disabling tests that fail due to core bugs). Once that's done I'll try to arrange a -dev release.

Overlay and aliases have been addressed.

Another change is that hook_boot has been moved to hook_init. This simplifies URL handling a quite a bit, and some benchmarks showed only a 30ms performance difference. The 302 responses are stored in the page cache for anon users which makes them very fast.

We still have core bugs to content with, but at this point I think it's ready for a -dev release.

Version:» 7.x-1.x-dev

-dev release is out! Gordon has requested that 7.x development be moved to HEAD, so going forward we'll be working there instead of DRUPAL-7--1.

We now have tests for path aliases, and the overlay issue has been addressed.

I installed it but did not see anyway to configure it under admin/config

the settings page is at /admin/structure/securepages

Thank You after a reinstall the link is now there!










I'm having some interesting issues with overlays - if I'm on a non-SSL page, and click an overlay link for a path that requires SSL, the page darkens, then completely redirects to the SSL path. And vice versa...

I have the 'Switch if path isn't in the required list' option turned on, so maybe I can just switch that off and things will be all right... But still, it'd be awesome if Overlay would work better with securepages.

[Update: Even with the switch setting 'off', I'm getting redirected to the actual overlay path instead of being able to visit the path inside an overlay.]

The overlay is fundamentally incompatible with mixed-mode SSL. You can't overlay a secure page on top of an insecure one, or vice versa, so the only option is to close the overlay when it triggers a redirect.

Would there be a way, though, to not switch if the overlay is active, but then switch outside of the context of the overlay?

We can't not switch under those conditions, because it defeats the purpose of the module, and it would additionally defeat core protection against hijacked sessions. #750104: Enforce https based on user role membership. would offer a way forward, because users that are likely to encounter the overlay (e.g. administrators) could be kept on SSL full-time.

I see; in that case, I will simply keep the 'switch' option turned off. For a site I just launched, https isn't causing any real increase in load, and I haven't heard any complaints about sessions remaining https throughout! (Though, that makes this module and Secure Login close in feature parity...




I'm surprised that mixed mode ssl is still not available for D7 since about all creditcard-checkout enabled shopping carts would need it. At least I do..

Yuri - I'm doing all I can; a full release is primarily being held up by the core issues linked in this issue summary. FWIW, the module works, try the -dev release. Depending on how you use the module, you may need to apply the core patches linked above.


Quick poll of subscribers - should Secure Pages work around the core bugs by including our own

Pros: We could create a stable release almost immediately.
Cons: Only one can be active, so it would exclude other contributed session handlers like

I vote for the quickest solution.

I think forking would be a bad idea since 3rd-party session storage solutions could no longer be used (mongodb, memcache) without some form of hacking. I'd suggest releasing at least an alpha or beta on the project page as is, and then linking to the remaining core issues from the project page as stable release blockers to get more eyes on those, and hopefully resolve them quickly.

I also vote for the quickest solution. A 7.x-2.0 version can be released when these core bugs will have been fixed.

I agree, first quick solution.

Quick solution for now. As that will help get to a stable release and we can go from there.

Hi Everyone. If it's more appropriate to spin this off into it's own ticket, let me know and I'll gladly create one. But this thread seems dedicated to the D7 port of secure pages, so I figure it's best to post it here.

There are at least two known issues blocking a stable release of secure pages
#1050746: HTTPS sessions not working in all cases
#471970: DrupalWebTestCase->getAbsoluteUrl should use internal browser's base URL

I posted in the first thread that I believe there is another issue with respect to http/https switching. Here is the overview

I have a clean D7 install with secure pages and the applied the two patches listed in the issue summary. Yesterday I was having some success, but I don't think I tested all the scenarios.

I've cleared cache numerous times. If I login at, it's still not registering being logged in when I go back to http and vice versa.

It is handing over items in the shopping cart but only when there isn't a session issue between the http/https connections. When there is, it's accessed denied or redirected back to HTTP.

I don't mind helping out with more testing, but others are claiming they are all set and I'm just not getting the expected behavior at the moment.

This was in response to -> rickmanelius: the securepages module already alters the login block's action URL to HTTPS. If this isn't working for you please open a support request in the secucepages queue.

In short, it appears that the login block is not being altered to use https and thus there are a lot of access denied issues when switching back and forth. I applied both the patches above, flushed the cache, and the issues are still there.

I'm an intermediate level drupal'er and will gladly help debug, if pointed in the right direction...

rickmanelius: There's a third patch in this issue summary - #961508: Dual http/https session cookies interfere with drupal_valid_token(). Do you have this one too? You also need to set $conf['https'] = TRUE in your settings.php. Since you've been participating in the review of the core patches, feel free to ping me in #drupal-contribute if you want to chat.

Regarding a future release: given the lack of significant traction on the core issues, I'm generally in favor of shipping a replacement for It's not quite as simple as applying the patches and copying the file though because one of the patches modifies, so I need to find a workaround for that that can be incorporated into

Hi @grendzy. It seems I misstepped when switching over to the fresh install. I didn't carry over the $conf['https'] = TRUE and that made all the difference.

So now I've combined all 3 patches + the settings.php adjustment and it's all set in terms of a working setup. Now whether other bugs exist, that's another story. But this is a great first step.

Re: your comment about core moving slow. When all put together, it seems they now work so can we just set reviewed by the community?

Thanks for the IRC note. I'll keep mine open and I can further assist with any debugging while meeting you in there. And thanks for your patience and feedback through this process.

I applied the latest patches from #961508: Dual http/https session cookies interfere with drupal_valid_token() and #1050746: HTTPS sessions not working in all cases and I also added $conf['https']=TRUE; to my settings, but sessions are not taking over to https. Should the patches only work for logged-in users?

We have an Drupal Commerce site up and running, and users are able to add items to their cart and thus starting the session without logging in. When SecurePages switches to https for the cart/checout process, the basket is empty again.

Hi Majestixs. Are you able to toggle on 'enabled' in admin/config/system/securepages? Did you try the third patch at #471970: DrupalWebTestCase->getAbsoluteUrl should use internal browser's base URL? Flush cache?

I was able to get a working ubercart transition from http to https as well as fully functional user login/logout. Please send along any additional information!

Coordinating the commit?

It seems when all 3 patches are combined with the settings.php configuration, they create a functional mixed SSL environment (see #39). Because they are spread across numerous issues, it seems like it's going to require some level of coordination or simultaneous review of all 3 in order to punch this through and get it committed to core before the 7.10 and 7.11 releases.

Should we use a modified/quick patch to for now until it can make it to the security review process? Or is that simply not going to happen because the security review needs to go through regardless of whether we do a modified instead of going through the process with all 3 patches?


Issue summary:View changes

remove i18n note

As they're currently written the 3 patches could be committed in any order - none of them break the tests. We just won't have a complete solution until all 3 make it.

We could consider combining one or more of the core issues... but what we really need is reviews. Our best shot at getting these committed is for Secure Pages users to post feedback on the core issues (even if only "it worked for me"). And if you've read the code, feel free to move the status to RTBC.

We have nearly 1500 users of the 7.x-dev branch, so I assume there's a significant number of sites using these patches successfully. We just need you to speak up!

I've updated the some issue summaries, and also linked to those issues from the Secure Pages home page.

Hi rickmanelius, after using all 3 patches, a cache flush and deletion of all browser cookies, this finally works! :)
I keep testing this and get back to you with feedback if I encounter any problems.

Thanks for your help! :)

I also confirm that I have tested the current Secure Pages module version 7.x-1.x-dev with the three patches applied and settings.php change as mentioned on the project page. I confirm that automatic switching between secure and unsecure pages now works.

I, too, have implemented the settings.php change and all three patches on a Drupal 7.9 installation running with the 7.x-1.x-dev (2011-Oct-10) version of Secure Pages. Things seem to be working as expected.

Hey, awesome work with the module. I am still working things out for my D7 install. But, it would be really helpful if the project page linked to specific patches/comments to apply to get the D7 version working. As someone who does not fully understand the issue and probably doesn't need to, it would be great to have a little more hand holding. :)

an other patched working drupal installation here :)

I just tried to apply all three patches, but all failed at multiple hunks. I am using Cygwin, but admittedly this is only my second time trying to apply a patch to a module. I followed these instructions:

I am assuming I did something wrong? These patches are still required, correct? Any guidance would be wonderful. Thank you.

I don't have experience in windows, but I had to add -p1 or patch would fail.

xlyz thank you for your tip. unfortunately I'm still getting failures with the -p1.

I have all the files in the same directory. I wish I knew what I was doing wrong. Here's some code if it provides any insights:

David@DAVID-PC /drupal
$ ls -al
total 40
drwxr-xr-x+ 1 David None    0 Jan 16 21:33 .
drwxr-xr-x+ 1 David root    0 Jan  7 13:56 ..
-rwxrwxrwx  1 David None 6152 Jan 16 21:10 1050746-POST-APOCALYPSE.patch
-rwxrwxrwx  1 David None 8653 Jan 16 21:13 471970-24.patch
-rwxrwxrwx  1 David None 1609 Jan 16 21:11 961508-23.patch
drwxr-xr-x+ 1 David None    0 Jan 16 21:04 original
-rwxrwxrwx  1 David None 8146 Jan 16 21:31 securepages.module
$ patch -p1 < 961508-23.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff --git a/core/includes/ b/core/includes/
|index 4229d52..ca9ccff 100644
|--- a/core/includes/
|+++ b/core/includes/
File to patch: securepages.module
patching file securepages.module
Hunk #1 FAILED at 4997.
1 out of 1 hunk FAILED -- saving rejects to file securepages.module.rej
can't find file to patch at input line 25
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
|diff --git a/core/includes/ b/core/includes/
|index a12fb34..c98211c 100644
|--- a/core/includes/
|+++ b/core/includes/

I'm definitely not going to patch D7 core for this module (or any other), so it's very unfortunate that the core bugs have not been resolved. Currently I can't wait for them.

Can anyone tell me it this module can be used at all in a D7 install without patching core? I would only need to force https on a few pages (such as login).

bibo: under some basic conditions it may be possible to use the module without core patches, but I wouldn't recommend it. The core bugs are too numerous and subtle to to be able to say 100% that an unpatched site won't encounter them.

If core patching is not an option for you, I'd suggest the securelogin module. Instead of implementing a mixed-mode, this module sends all authenticated users to HTTPS and so sidesteps the core bugs.

I've been using Secure Pages since August on a couple D7 sites without patching core, and haven't found any problems. All I have set up is an SSL/non-SSL mixed environment, and the SSL-required pages are always redirected to correctly... once the user is on an SSL page, the rest of their session (wherever they go) will be SSL unless they specifically visit a non-SSL link.

geerlingguy - did you just set $conf['https'] = TRUE; in settings.php without applying the above three patches? Essentially all I want to do is create secure register and login pages.

@starbucksguy - Here's my production server config array for secure pages settings:

$conf = array(
// Allow secure sessions (@see http_://
'https' => TRUE,
'securepages_basepath' => 'http://' . $host,
'securepages_basepath_ssl' => 'https://' . $host,
'securepages_enable' => 1,
'securepages_switch' => 0,

I have the 'Switch back to http pages when there are no matches' checkbox unchecked, and I'm using 'Make secure only the listed pages'. I'm ignoring the following paths:


bibo: under some basic conditions it may be possible to use the module without core patches, but I wouldn't recommend it. The core bugs are too numerous and subtle to to be able to say 100% that an unpatched site won't encounter them.

If core patching is not an option for you, I'd suggest the securelogin module. Instead of implementing a mixed-mode, this module sends all authenticated users to HTTPS and so sidesteps the core bugs.

Thank you for this answer. We won't use securelogin for now, as we are actually going to cache a lot of authenticated traffic in varnish (https would make caching quite a bit harder / less efficient).

Also thanks to geerlingguy & starbucksguy .

geerlingguy -- Thank you for taking the time to share your code with me; it's very helpful.

bibo - Your comment about caching through varnish set me off on a little google research. I learned a lot, but perhaps I might private message you at some point to pick your brain some more.

bibo - Your comment about caching through varnish set me off on a little google research. I learned a lot, but perhaps I might private message you at some point to pick your brain some more.

You're welcome to do so, I've also spent quite a bit of effort on figuring things out. But a quick tip for a less known module that offers a partitial solution to this challenge:

So I have been able to use this module with the code in #55 and everything seems to work for me.

geerlingguy: Thanks again for sharing that.

Does it look like I entered geerlingguy's suggested code properly (#55) in my settings.php? this is what I have:

* Base URL (optional).
* If Drupal is generating incorrect URLs on your site, which could
* be in HTML headers (links to CSS and JS files) or visible links on pages
* (such as in menus), uncomment the Base URL statement below (remove the
* leading hash sign) and fill in the absolute URL to your Drupal installation.
* You might also want to force users to use a given domain.
* See the .htaccess file for more information.
* Examples:
*   $base_url = '';
*   $base_url = '';
*   $base_url = '';
*   $base_url = '';
* It is not allowed to have a trailing slash; Drupal will add it
* for you.
# $base_url = '';  // NO trailing slash!
    $host = $_SERVER['HTTP_HOST'];
    $conf = array(
      // Allow secure sessions (@see http_://
      'https' => TRUE,
      'securepages_basepath' => 'http://' . $host,
      'securepages_basepath_ssl' => 'https://' . $host,
      'securepages_enable' => 1,
      'securepages_switch' => 0,
* PHP settings:
* To see what PHP settings are possible, including whether they can be set at
* runtime (by using ini_set()), read the PHP documentation:

I didn't include the opening and closing php tags because I figured they were already present in the file.

In any case, I am not getting an SSL/non-SSL mixed environment. Once logged-in, authenticated user sessions remain SSL. In fact, I don't think the user actually has to login or register; visiting those pages is enough to permanently switch over to SSL.

I tried configuring the setting both through "all pages except those listed" and "only those pages listed" with the same unsuccessful results. It's also worth noting that the 'Switch back to http pages when there are no matches' checkbox will not stay enabled when I save the configurations.

I hope I'm not taking this issue off course. Thank you all for the time you have already invested in resolving this problem.

The reason I don't have the "switch back to non-ssl" checkbox checked is that it didn't work, and it's more secure anyways to keep a user in a secure session once they've done something that does require SSL... The only feature I get out of secure pages, really, is the ability to have most things show as non-SSL, but to foce a switch to SSL on certain paths.

Yes, I really just want the user/login and user/register paths secure, but I'm not switching back to non-SSL for some reason. Does it look like I implemented your code correctly? Maybe for some reason it is just not going to work on my setup.

starbucksguy: if you force the conf values in settings.php, then they can't be changed in the admin page. Using settings.php normally isn't necessary, just set the values you want at /admin/config... You can leave the base URLs blank and the host is auto-detected.

starbucksguy: When I added it I changed the line

  'securepages_switch' => 0,


  'securepages_switch' => 1,

From what others have said the switching back and forth isn't ready. I though I'd give it a shot and it seems to work in my testing. I'm using it to redirect on user*, cart* and checkout* for a Commerce site.

I am happy to report that with grendzy's guidance I was able to secure login, registration and my account pages by simply inserting $conf['https'] = TRUE; in settings.php and entering the appropriate settings in the module's configuration page.

I've been successful applying the 3 pages + updating the settings.php file to achieve mixed mode http/https.

However, there is one remaining bug with Safari (5.1.2 on OS X 10.7.2) and Varnish. When you login to https and then move back to http, Varnish continues to hit as long as you simply click onto http pages. If you hit refresh, safari THEN bypasses varnish and recognizes you're logged in after that.

This problem does not affect IE9, chrome, or firefox. All of these completely respond appropriately and immediately. It has to be varnish related as the mixed mode login works perfectly on my local with ssl certs for testing purposes.

Here are the patches I'm using:

What is confusing me is why Safari (both web and iphone versions) behaves differently here and requires a user to refresh before varnish is ignored. Thoughts?

Ignore #66.
It's actually Safari + Varnish related.

This is, therefore, not a secure pages issue.

FWIW, I applied all 3 patches (my first time applying patches, woohoo!) and edited my settings.php and everything is working how it should on my site. It's a pretty basic setup, but I thought I'd post that here as my two cents.

I had this working fine for a commerce site switching to https for checkout pages. Just yesterday though whilst doing some irrelative test with a test account I discovered that for a particular account when switching from http to https the session is lost, the user is logged out and I get a page not found error. When I try the same process with the admin account, everything seems to work.
Any ideas on how I can debug this?

@mxa055 — did you do the Steps to install from above? (The settings.php and three patches.) Mine didn't work until I did that.

Yes mine didn't work at all until I followed all the above steps. After applying them it worked.
After some more testing yesterday I noticed that if I logout and re-login and try to go to a https page I get logged out and get a page not found. If I relogin at that page, then everything works fine (http=>https=>http) until I logout again.

It seems that I lose the session when going from HTTP to HTTPS for the first time. But if I login in https then everything works as expected.

When I login on http page and go to an https page I get two entries in the session table. One for the user which is insecure (without SSID) and one secure (with SSID) for the anonymous user.

I found the problem...well not really the problem, but at lease I found the solution. I had edited the paths that would be secured and only left checkout/*. After adding the user/* and the rest of the original paths everything is back to normal.

Those of you monitoring this thread who've done successful patching .... can you please answer the question in ? It would be useful to have this info in a shorter thread (since clearly my attempt to figure it out here failed!). Thanks much.

We were running into the same issue as @mxa055 in #69 and found we too had removed many of the defaults (including user/*). Once we added user/* back, everything seems to work. Does this not seem to indicate that there is a problem with sessions getting passed from HTTP to HTTPS, since it only seems to actually work in the other direction? I would think that very few people would notice if they leave the default paths alone, but...

It's impossible to create a secure mixed session over HTTP. Since sessions are created / regenerated during login, this fact implies that user/login must be HTTPS. I'm not sure what the best way would be to enforce or warn about this, though.

What about using secure login + secure pages?

securepages with "pages: user/login" and "User roles: authenticated user" checked on the settings page would provide the same behavior as securelogin.

Trying to use both modules together would provide no benefit, and almost certainly result in conflicts.

Thanks for the info

I just wanted to confirm that the only patches I could get to work with D7 (latest) were the following:

Those aren't the exact patches referenced on the project page but all 7.x patches in those two threads failed. It took me quite a while to figure this out since I had to move up through the threads (about 2-3 patches each) before finding these. And that doesn't include all the 8.x patches in there which could make it even more confusing to someone trying to apply them.

Would it be possible to link directly to these patches (or whatever the correct ones are) from the project page until they're committed to core?



The project page already links to specific patches - I re-tested them today against 7.x, and both applied with small offsets (ignore the testbot status, it's reporting against D8).

Right...but the reason for my post was that the project page links to: for dual http/https

Which doesn't work with the latest version of D7 while does.

The other seems to now be corrected...

Maybe I'm missing something here but I went through quite a few patches (none of which were D8) before determining the ones in my last post worked. I thought I might save someone else the time.

961508-20.patch is still working for me.

[dylan@mb ~/Sites/d7/drupal (7.x)]$ git pull
Already up-to-date.
[dylan@mb ~/Sites/d7/drupal (7.x)]$ curl | patch -p1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1569  100  1569    0     0   3493      0 --:--:-- --:--:-- --:--:-- 44828
patching file includes/
Hunk #1 succeeded at 5035 (offset 162 lines).
patching file includes/
Hunk #1 succeeded at 1127 (offset 26 lines).

Maybe it's because I'm on 7.15 and not 7.x-dev? I'll test again with a fresh install of 7.15 to confirm so no one is wasting any time.

This might be just a documentation issue. I'd expect there's more users out there on the latest stable than dev -- especially in terms of core.

All patches should be rolled for -dev.

After this exchange I've realized that but I consider myself okay at Drupal and ended up losing quite a bit of time here because the project page pointed to patches to the dev version of Drupal core and I was using the latest stable version.

I guess my only suggestion is that this be documented a bit better. I use a ton of dev modules but have never used dev on Drupal core for production. Since most of my projects are ecom and it's against PCI compliance to take cards w/o SSL this module is a must. So I have to use it in prod.

But maybe I'm the only one out here that doesn't get this process. A very likely case. ;)

Maybe one day this functionality will be in Drupal core. Seems like it should be...


dwatts3624, I think you may have downloaded the wrong patch by accident. As demonstrated above the patch linked from the project home page applies to 7.x-dev, and I've also spot-tested it with 7.0, 7.10, and 7.15.

For Drupal 7.17 the two following patches apply successfully:

And I assumed that most of the the third one 1050746-POST-APOCALYPSE_0.patch it´s already in the file that ships with Drupal core since 7.13, right? So I skipped it. Then, I made sure that I was covering the following points that I found in the Secure Pages issues as the most relevant ones for achieving a mixed HTTP/HTTPS session in Drupal 7:

  • Use $conf['https'] = TRUE; in settings.php.
  • Apply TRUNCATE sessions; to the the database.
  • Log in/Log out with an authenticated user, and then try the mixed session as anonymous user.

However, after checking several times if I was doing the correct thing, it didn´t work.
And there was a specially frustrating thing: It has been working in my development server, but when moving changes to production, mixed sessions failed, although I was using the same patches, same code base, etc... This made me focus on the server environment and I realized that the sessions table of the drupal installation where mixed session works had the following serialized format for session column:

| uid | sid        | ssid       | timestamp  | session                                                                     |
|   0 | 2P5GBvR... | 5r6ic5r... | 1353241664 | uc_cart_id|s:32:"1a7593b7c7c094387176c02c8c242c85"

While this is how looks like the sessions table of the drupal installation where things didn´t work:

| uid | sid        | ssid       | timestamp  | session                                                                     |
|   0 | juySgDI... |            | 1353242016 | 6e4vbt6ypjAxl-1RXMy7poLNvCskffZfcTEB6HGfX-mIzq9C...

Session data was encrypted in my production server where I was using php5-suhosin. After disabling suhosin Transparent Encryption with suhosin.session.encrypt = off in /etc/php5/apache2/conf.d/suhosin.ini, mixed sessions WORKED! And I guess that it could be disabled as well in php.ini file, or even in setting.php by using ini_set(), depending on the server configuration files. It should be safe to disable suhosin.session.encrypt as long as there´s a web application on the server that already does session validation (which I assume is the case of Drupal).

I´m not an expert and never expected that such a thing was interfering with the hints provided here. I´m just mentioning it here with the hope it may be of use for someone experimenting a hard time making mixed sessions work.

I'll agree with comment #85...

ALSO, I highly recommend that the documentation states that the cookie domain might need to be set in the settings.php file in order for things to work properly.

I got a solution to this problem ,

enable https in settings.php as usual ,

ie, add this code to end of settings.php

$conf['https'] = TRUE;

then the main trick is , make 'user' and 'user/login' as https , through secure pages . then all other pages works, my application was for ubercart 'cart , checkout pages on encryption' all other pages are non encrypted.

it seems like the problem is https add some encryption to session id , when the user logged in with https it get session id which can be used in both https and http pages , but on the reverse its was not working.


I experience the exact same behavior as @mssarath in #89.

Thanks! I had everything working with mixed mode in all browsers but Chrome. Once I set the cookie domain, the issue was resolved.

#89 is right. When the login is processed on a secure page the session is preserved between secure and unsecure pages.

Has anyone tried the recommended patches on 7.22? I'm getting minimal joy here.

Issue summary:View changes

adapt to installation instructions