On Tue, 01 Nov 2011 12:05:57 -0700, Brion Vibber wrote:
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
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.
--
-- Dan Nessett