On Tue, 01 Nov 2011 12:05:57 -0700, Brion Vibber wrote:
On Tue, Nov 1, 2011 at 11:43 AM, Dan Nessett dnessett@yahoo.com wrote:
So, while I still believe there is a problem with PHP sessions, I cannot yet reproduce the intermittent problem we observe. However, other improper behavior is reproducible.
For example on both MW 1.16.2 and MW 1.16.5 if you execute the procedure specified earlier in this thread up to the point where an edit is attempted (i.e., log in and wait 60 seconds). Then instead of editing, simply refresh the page, the line at the top of the page still shows the user logged in. However, the session record changes from (before the 60 second timeout):
wsUserID|i:1;wsToken|
s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName|
s:9:"WikiSysop";wsLoginToken|N;
to (after the page refresh):
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
It isn't clear why the session file remains after the page refresh, since it should have been cleared by the PHP garbage collector. Furthermore, it isn't clear why the session record contains a wsUserName value of WikiSysop. Since the user is logged out (although this isn't indicated on the browser page), the session record should show an anonymous user.
This looks like expected behavior to me:
- initial login sets up a real session, including the wsToken value
which is used to confirm validity
- ... times out...
- browser makes a request for the refresh, including an
If-Modified-Since header with the previous page's Last-Modified timestamp * MW sees there's a session cookie and calls PHP's session setup * PHP session setup garbage-collects old session files * PHP session setup sees the ID from the cookie, sees there's no session file, and creates a new session file
- MW sees an empty session and initializes the user ID and name from
cookies.
- MW sees that there's no saved token cookie or token info in the
session, so you get an anonymous user.
- [On < 1.16.5 you may also hit the bug that the permissions of the
previously-identified user get left in the anonymous user object.] * MW sees that there's an If-Modified-Since header. The page hasn't been modified since that time, and there's no user_touched timestamp for the anonymous user, so it returns a "304 Not Modified" response * browser shows the cached page, with the user name showing as if still logged in
Fiddling around moving things from Last-Modified to Etags should make it easier in the future for us to return a non-stale page in this situation, since we can compare the user ID as part of the tag. You'll find an enhancement request for this in BZ: < https://bugzilla.wikimedia.org/show_bug.cgi?id=31639%3E
If you refresh the page again, the logged in/out line is properly displayed as logged out, but the session record has not changed. That is, it still equals:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
These are filled in from the cookies, this is expected.
Finally, sometimes when logging in after refreshing the page twice, the
following error message is displayed:
"Login error There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again."
The session data at this point reads:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";wsLoginToken| s:32:"3bc03a309dd80ff94633dc6b43218309";
This appears to improperly associate the username WikiSysop with an anonymous login token.
wsLoginToken appears to be just a CSRF protection for the login form, and isn't attached to specific users.
This may indicate that your session is expiring again, or is otherwise being stomped on somehow.
-- brion
This problem is a bear to analyze. I have not been able to develop a reliable way to reproduce the problem. However, I have found a way to reproduce a related problem intermittently. I have put details in the bug report - https://bugzilla.wikimedia.org/show_bug.cgi?id=32122.