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.
Comment | File | Size | Author |
---|---|---|---|
#17 | securepages-insecure_regenerate-1545970-17.patch | 684 bytes | make77 |
#16 | 1545970-securepages-insecure-generate-16.patch | 754 bytes | sadashiv |
#12 | 1545970-securepages-insecure-regenerate-12.patch | 703 bytes | make77 |
#11 | 1545970-securepages-insecure-regenerate-10.patch | 703 bytes | make77 |
#10 | 1545970.10-securepages-insecure-regenerate.patch | 701 bytes | mrfelton |
Comments
Comment #1
grendzy CreditAttribution: grendzy commentedThis 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.
Comment #2
teunis CreditAttribution: teunis commentedsteps: (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)
Comment #3
teunis CreditAttribution: teunis commented"truncate sessions" did not fix.
Comment #4
grendzy CreditAttribution: grendzy commentedAh, 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.
Comment #5
teunis CreditAttribution: teunis commentedNot an option in our case, however we re-create the sessions via drupal_session_regenerate() now when going to https - and that works.
Comment #6
grendzy CreditAttribution: grendzy commentedGlad 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.
Comment #7
mrfelton CreditAttribution: mrfelton commentedIf 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.
Comment #8
teunis CreditAttribution: teunis commented#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.
Comment #9
grendzy CreditAttribution: grendzy commentedThe 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).
Comment #10
mrfelton CreditAttribution: mrfelton commentedHere is the patch from #6, which has been working for us.
Comment #11
make77 CreditAttribution: make77 commentedIn 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.
Comment #12
make77 CreditAttribution: make77 commentedIn 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.
Comment #13
webservant316 CreditAttribution: webservant316 commentedI 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.
Comment #14
sadashiv CreditAttribution: sadashiv commentedI 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
Comment #15
ditcheva CreditAttribution: ditcheva commented@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'...
Comment #16
sadashiv CreditAttribution: sadashiv commentedHi,
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.
Comment #17
make77 CreditAttribution: make77 commentedI couldn't reproduce problem from #16 but I updated patch #12 with latest version module.