if ssid is empty on a session, a new session is generated.

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.

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.

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) {
      drupal_session_regenerate();
    }
  }
}

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.

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

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

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.

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.

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.

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

@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'...

Hi,

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.

Hth,
Sadashiv.

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