[Mediawiki-l] MW seems to get confused when IP address of client machine changes while user is logged in

[Dan Nessett]

On Tue, 01 Nov 2011 12:05:57 -0700, Brion Vibber wrote:

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