From:             [EMAIL PROTECTED]
Operating system: Debian GNU/Linux 2.2
PHP version:      4.0.3pl1
PHP Bug Type:     *Session related
Bug description:  Session write-out race condition

Initally from time to time, very rarely, we'd login to the site (which does logins as 
a form submission), and we'd get back to the page we're supposed to be at but without 
seeming to be logged in. 

The page that the login form submits to does very little, it just checks the details 
provided by the form in a database, and sets a session variable with the user's real 
ID, which all pages consider to be "logged in". Then, they're redirected back to the 
refering page. 

Works fine, 99.9% of the time, but under situations where access is good (eg, 50ms 
away from the webserver over cable + ethernet) sometimes it just wouldn't work. It got 
a _lot_ worse when we started pushing session data into a database.

Initally we thought it was our custom session save stuff, but removing it we could 
still reproduce the problem (it was just harder to reproduce). Finally, we added a 
whole lot of debugging calls to error_log() and found what was going on.

There's a race condition between the end of a page and when the session handler 
actually writes out the session data, vs when a new page is requested. If the remote 
browser requests a page before PHP has written out the session stuff, it'll get the 
old session infomation. From our debugging:

[Sat Mar 10 21:58:49 2001] [error] uri:
/login.php?user=samteste&password=x&uri=%2F sql: select
[Sat Mar 10 21:58:49 2001] [error] uri: / sql: SELECT value FROM sessiondata WHERE 
sesskey =
'35760d1b61748cc467b3c685916c3980' AND expiry > now()
[Sat Mar 10 21:58:49 2001] [error] uri:
/login.php?user=samteste&password=x&uri=%2F sql:
        UPDATE sessiondata
        SET    expiry = now()+'1440s',
               value = 'playerid|s:4:\"1542\";attempt|i:1;'
        WHERE  sesskey = '35760d1b61748cc467b3c685916c3980'

Roughly, we see this sequence as:
 - The page that verifies the login is called (/login.php), and the login is verified, 
which updates the session variable. Before exit, this page issues a redirect to /.
 - The browser then processes the redirect, and requests the new URL (/), retriving 
the "current" session data
 - The session data from login.php is only just now written out.

We have a workaround in PHP (we have a function called redirect() which first calls 
our session_write handler with the session_id() and session_encode(), before outputing 
the headers..) but we'd prefer the session handling worked as advertised, so to speak 

Note: we've verified with a packet sniffer that the browser is closing the connection 
before opening a new one for the new URL. It's not the browser jumping the gun. 

Edit Bug report at:

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to