On Tue, Nov 1, 2011 at 11:43 AM, Dan Nessett <dnessett(a)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>
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