On Tue, Nov 1, 2011 at 11:43 AM, Dan Nessett <[email protected]> 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 _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
