if ssid is empty on a session, a new session is generated.
Specifically - if you update a site with the patches for secure pages but use an existing session, your session is not upgraded to work and is instead replaced - for https.
if you switch back to http, the old session is used instead.

Suggestion : have a way to invalidate sessions where ssid is blank when securepages is enabled?

I'm a little unclear on what to do, other than it impacts http://drupal.org/node/1050746 (HTTPS sessions not working in all cases)
Perhaps I can instruct the customer to clear out sessions where ssid='' after they've updated.

Members fund testing for the Drupal project. Drupal Association Learn more


grendzy’s picture

Status: Active » Closed (duplicate)

This is really tied to changing $conf['https']. When the session handler's behavior is reconfigured like this, existing data in the session table becomes invalid. The solution is to run TRUNCATE sessions after changing settings.php.

Since it's trigged by a settings.php change, and not action taken by the module, I don't think there's a way we can clear this programmatically. The best we can do is improve the documentation.

To keep the doc issue centralized, I've added a note to #1358424: Improve securepages documentation and am closing this as a duplicate.

teunis’s picture

Status: Closed (duplicate) » Active

steps: (note, anonymous user)
1. go to website
2. do something that sets a session variable
3. switch to https and set another session variable
4. switch to http, and session in 3 is ignored
5. switch to https and session set in 3 is overwritten.

It's looking (according to coworker) that drupal_session_regenerate is not being called except when logged in (not anonymous)

teunis’s picture

"truncate sessions" did not fix.

grendzy’s picture

Ah, I see. Mixed sessions must be created via HTTPS. So if for example cart/add/* is creating the session, just make sure that page is HTTPS. After the initial creation session data will be saved as you switch back and forth.

Drupal core does't support upgrading of sessions, except during login. If there were a really compelling use case for this, we could work on another core patch. Given the difficulty of getting session patches reviewed however, I'd suggest just making sure your sessions get created via HTTPS.

teunis’s picture

Status: Active » Closed (works as designed)

Not an option in our case, however we re-create the sessions via drupal_session_regenerate() now when going to https - and that works.

grendzy’s picture

Glad you found a way around it. I was experimenting with it a little bit too, and found (I think) a similar solution. It does seem to work, although it leaves behind an extra row in the sessions table after regeneration. Please do be aware that if you don't create the session over HTTPS then it's vulnerable to hijacking until it's regenerated.

function hook_init() {
  global $is_https;
  if ($is_https && user_is_anonymous()) {
    $insecure_session = db_query("SELECT 1 FROM sessions WHERE sid = :name AND ssid = ''", array(':name' => $_COOKIE[substr(session_name(), 1)]))->fetchField();
    if ($insecure_session) {
mrfelton’s picture

Status: Closed (works as designed) » Active

If the code in #6 works (looks like it should) can something like this be added to securepages? I don't think its very realistic to assume that the the page that first creates a session is a page that needs to be served over https.

We have this problem with commerce. We could possibly add cart/add/* in the list of securepages includes, but there is nothing to say that this is the first thing that will set the session. For example, we use Views to display our product catalog, and the view has exposed sort and pager options. We have set up Views to remember exposed sort/pager settings which means that if anyone uses one of the exposed sort options or pager settings, then they get an anonymous session with a blank ssid.

teunis’s picture

#6 looks like a good approach - or perhaps something like this could be done in the core session handling? That extra row is always generated when the 'insecure' session is created, and is in essence the cause of the difficulties I encountered.

It's not reasonable to require that only a secure session is ever made. However once a secure session is generated, the insecure session needs to be disposed of, I'd think.

grendzy’s picture

The problem with regenerating the session this way is it would probably cause failures if the page triggering the regeneration depended on the session_id value. (for examples form submissions, or anything with a token created by drupal_get_token).

The other option would be to upgrade the session in-place: setting a secure cookie, and modifying the ssid column of the sessions table. I think this would work pretty universally, the main risk is an attacker could steal and upgrade the session before the visitor did, in which case the visitor's session would be invalid. A man-in-the-middle can already unset cookies though so this may not be a big deal.

And of course, anytime we meddle with the sessions table it means those features won't work on sites using a non-sql session handler (like memcached).

mrfelton’s picture

Status: Active » Needs review
701 bytes

Here is the patch from #6, which has been working for us.

make77’s picture

In patch #10, the table name misses braces in query. It can cause error when the table is prefixed. Here is a new patch with correction.

make77’s picture

In patch #10, the table name misses braces in query. It can cause error when the table is prefixed. Here is a new patch with correction.

webservant316’s picture

I am noticing weird https / session interaction in 7.x-beta2. Is this patch installed? Is this problem fixed? Whenever I load an https page the session appears to be lost. When I return to http it is there again.

sadashiv’s picture

I am facing the same issue as specified in #13. When I visit a link having a https and if the page sets a message using drupal_set_message then the message is not shown on the next page after redirecting but is shown when I visit another page having https so seems that both sessions are different and causing issues.

Also sometimes when anonymous users add products to cart they are not added to the cart as the cart has https enabled and they are shown added after visiting other page

ditcheva’s picture

@webservant316, @sadashiv, no, the patch hasn't been committed yet. Would you be able to test the patch in #12 and see if it fixes the issue and report back? The issue is still marked as 'Needs Review'...

sadashiv’s picture


Patch #12 works fine on a clean install. #12 should fix this issue. For some reason may be due to other module or caching configurations(for my site) drupal didn't set a cookie with sid so the non https page is considered as separate session. I handled that by modifying the patch. I am attaching that with this comment.


make77’s picture

I couldn't reproduce problem from #16 but I updated patch #12 with latest version module.