#2538 SM 1.4.11: Deleted session handling

closed-fixed
None
5
2008-02-13
2007-11-09
Bernd Nies
No

Hi,

We have the following server setup:
- Solaris 9
- Apache/2.2.4 (Unix) DAV/2 mod_ssl/2.2.4 OpenSSL/0.9.8e PHP/5.2.2
- Squirrelmail 1.4.11
- Plugins: aboook_import_export 1.1, avelsieve 1.9.4, quota_usage 1.3.1, useracl 2.1

Squirremail runs behind a web proxy which does session and cookie management. We use this proxy to authenticate and authorize remote users for various applications.

When one clicks "Sign Out" on the Squirrelmail, then PHP terminates the session and sends the following HTTP header to the browser (or in our case to the proxy):

Set-Cookie: SQMSESSID=deleted; expires=Thu, 09-Nov-2006 13:34:48 GMT; path=/

Unfortunately the proxy implementation ignores the old HTTP 1.0 cookie expires option and does not delete the cookie. It only looks at the 'max-age' option:

RFC 2109 --> 10.1.2 Expires and Max-Age

Netscape's original proposal defined an Expires header that took a
date value in a fixed-length variant format in place of Max-Age:

Wdy, DD-Mon-YY HH:MM:SS GMT

Note that the Expires date format contains embedded spaces, and that
"old" cookies did not have quotes around values. Clients that
implement to this specification should be aware of "old" cookies and
Expires.

http://tools.ietf.org/html/rfc2109
http://de.wikipedia.org/wiki/HTTP-Cookie

The expires option is also not very reliable. What if the clock of the remote system is some years behind?

The problem now ist, that the proxy sends the cookie SQMSESSID=deleted back to Squirrelmail and Squirrelmail interprets this as a valid session. This happened in our setup and many users which were logged in at the same time had the session and preferences of another who logged out previously.

Proposed fix: In functions/global.php in the function

function sqsession_is_active() {
@session_start();
}

Capture the event when the Cookie PHPSESSID (or which name ever is configured in config.php) contains the string "deleted" or something different than the random session ID generated by PHP and do not treat it as a valid session. I'm not sure if this fix should go down to the PHP layer because already there this is already treatened as a valid session.

Bye
Bernd

Discussion

  • Logged In: YES
    user_id=620333
    Originator: NO

    The "deleted" value is not somethign we're sending. That's a PHP bug. If you look at the code in functions/global.php for sqsession_destroy, we issue a setcookie, with no value, and a timestamp of 0. According to the PHP docs, this should set a cookie which expires at the end of the browser session.

    It appears, however, that PHP is caching the headers to be sent, and overwriting our header with its own. This is causing two bugs. The first is the value being set to 'deleted'. This is a problem, and has been noted in the past, that causes sessions between different users to merge. And the bug you're mentioning.

     
  • Logged In: YES
    user_id=620333
    Originator: NO

    The patch attached to bug #1829005 should also cover this issue.

     
    • assigned_to: nobody --> jangliss
     
  • Logged In: YES
    user_id=620333
    Originator: NO

    Doing some searching, IE doesn't support the Max-Age feature, so it's not RFC2109 compliant (which was obsoleted by RFC2965). The best we can do is alter the way the cookie is set, and force a value, but set a date way back in the past [1970] to try and account for inaccurate times. The code changes mentioned in 1829005 use that logic.

     
    • status: open --> pending-fixed
     
  • Logged In: YES
    user_id=508228
    Originator: NO

    Please update to the last release of SM; it sets the cookie date to "1", which should be old enough to have the cookie removed, regardless of the "deleted" text. I am setting this tracker to pending, as I believe it has been resolved, but please reply if not.

     
    • status: pending-fixed --> closed-fixed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).