We have been experiencing problems with MW 1.16.2 related to logged in users on client machines where the IP address changes. I have looked over the Bugzilla reports but could not find anything obviously related.
If a user with a laptop logs into the wiki, puts the laptop to sleep, moves to a different location and then attempts to continue processing, the logs show his changes mapped to an IP address (or on one of our wikis as anonymous), rather than his user name. A simple thought experiment suggests the cookie presented to the wiki after the laptop move has a different IP address than the request message. This confuses MW, giving the user all his permissions (since he is logged in), but not properly identifying the user's name in the logs.
Has anyone else observed this and if so, are there ways to address this issue?
On Mon, Oct 10, 2011 at 11:16 AM, Dan Nessett dnessett@yahoo.com wrote:
We have been experiencing problems with MW 1.16.2 related to logged in users on client machines where the IP address changes. I have looked over the Bugzilla reports but could not find anything obviously related.
If a user with a laptop logs into the wiki, puts the laptop to sleep, moves to a different location and then attempts to continue processing, the logs show his changes mapped to an IP address (or on one of our wikis as anonymous), rather than his user name. A simple thought experiment suggests the cookie presented to the wiki after the laptop move has a different IP address than the request message. This confuses MW, giving the user all his permissions (since he is logged in), but not properly identifying the user's name in the logs.
Session cookies are not tied to IP addresses. Most likely, the session has simply expired -- it won't make a difference whether you come back on a different IP or the same one, expired session data will kill your login.
Note that in the case of session expiration, the caching workaround that we perform on logout (setting a 'logged out at time X' cookie) doesn't work, so you may initially see a couple page views that still look like you're logged in. You should not see this confusion on the actual edit page itself -- this won't be cached so should show you that you are not logged out.
Consider increasing PHP's session lifetime: http://us2.php.net/manual/en/session.configuration.php#ini.session.gc-maxlif...
the default is 1440 seconds (24 minutes), meaning that a session which doesn't get touched for 24 minutes may get destroyed during garbage collection.
It's also possible that there's something else in your system which introduces an IP-address dependency for sessions, such as the session encryption option in the suhosin plugin with some unsafe configuration options used:
http://www.hardened-php.net/suhosin/configuration.html#suhosin.session.check...
-- brion
On Mon, 10 Oct 2011 12:44:57 -0700, Brion Vibber wrote:
On Mon, Oct 10, 2011 at 11:16 AM, Dan Nessett dnessett@yahoo.com wrote:
We have been experiencing problems with MW 1.16.2 related to logged in users on client machines where the IP address changes. I have looked over the Bugzilla reports but could not find anything obviously related.
If a user with a laptop logs into the wiki, puts the laptop to sleep, moves to a different location and then attempts to continue processing, the logs show his changes mapped to an IP address (or on one of our wikis as anonymous), rather than his user name. A simple thought experiment suggests the cookie presented to the wiki after the laptop move has a different IP address than the request message. This confuses MW, giving the user all his permissions (since he is logged in), but not properly identifying the user's name in the logs.
Session cookies are not tied to IP addresses. Most likely, the session has simply expired -- it won't make a difference whether you come back on a different IP or the same one, expired session data will kill your login.
Note that in the case of session expiration, the caching workaround that we perform on logout (setting a 'logged out at time X' cookie) doesn't work, so you may initially see a couple page views that still look like you're logged in. You should not see this confusion on the actual edit page itself -- this won't be cached so should show you that you are not logged out.
Consider increasing PHP's session lifetime: http://us2.php.net/manual/en/session.configuration.php#ini.session.gc-
maxlifetime
the default is 1440 seconds (24 minutes), meaning that a session which doesn't get touched for 24 minutes may get destroyed during garbage collection.
It's also possible that there's something else in your system which introduces an IP-address dependency for sessions, such as the session encryption option in the suhosin plugin with some unsafe configuration options used:
configuration.html#suhosin.session.checkraddr
-- brion
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
On Tue, 11 Oct 2011 17:17:04 +0000, Dan Nessett wrote:
On Mon, 10 Oct 2011 12:44:57 -0700, Brion Vibber wrote:
On Mon, Oct 10, 2011 at 11:16 AM, Dan Nessett dnessett@yahoo.com wrote:
We have been experiencing problems with MW 1.16.2 related to logged in users on client machines where the IP address changes. I have looked over the Bugzilla reports but could not find anything obviously related.
If a user with a laptop logs into the wiki, puts the laptop to sleep, moves to a different location and then attempts to continue processing, the logs show his changes mapped to an IP address (or on one of our wikis as anonymous), rather than his user name. A simple thought experiment suggests the cookie presented to the wiki after the laptop move has a different IP address than the request message. This confuses MW, giving the user all his permissions (since he is logged in), but not properly identifying the user's name in the logs.
Session cookies are not tied to IP addresses. Most likely, the session has simply expired -- it won't make a difference whether you come back on a different IP or the same one, expired session data will kill your login.
Note that in the case of session expiration, the caching workaround that we perform on logout (setting a 'logged out at time X' cookie) doesn't work, so you may initially see a couple page views that still look like you're logged in. You should not see this confusion on the actual edit page itself -- this won't be cached so should show you that you are not logged out.
Consider increasing PHP's session lifetime: http://us2.php.net/manual/en/session.configuration.php#ini.session.gc-
maxlifetime
the default is 1440 seconds (24 minutes), meaning that a session which doesn't get touched for 24 minutes may get destroyed during garbage collection.
It's also possible that there's something else in your system which introduces an IP-address dependency for sessions, such as the session encryption option in the suhosin plugin with some unsafe configuration options used:
configuration.html#suhosin.session.checkraddr
-- brion
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
I need to clarify one thing. For a revision deletion/restore, the identifier "Anonymous" appears in the deletion log, not in Recent Changes, which has the IP address of the request). Recent changes always records the IP address.
On Tue, Oct 11, 2011 at 10:17 AM, Dan Nessett dnessett@yahoo.com wrote:
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
Ok, my suspicion is on https://bugzilla.wikimedia.org/show_bug.cgi?id=28639, fixed in the 1.16.5 security release in May: < http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-May/000098.html
It looks like there may be some cases where session expiration (or similar issues) might have left things in a state where the previous user's permissions got kept but the other info got thrown away. This would presumably allow edits etc to finish up, while recording them as not a user id.
-- brion
On Tue, 11 Oct 2011 14:37:56 -0700, Brion Vibber wrote:
On Tue, Oct 11, 2011 at 10:17 AM, Dan Nessett dnessett@yahoo.com wrote:
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
Ok, my suspicion is on https://bugzilla.wikimedia.org/show_bug.cgi?id=28639, fixed in the 1.16.5 security release in May: < http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-
May/000098.html
It looks like there may be some cases where session expiration (or similar issues) might have left things in a state where the previous user's permissions got kept but the other info got thrown away. This would presumably allow edits etc to finish up, while recording them as not a user id.
-- brion
Thanks. I will upgrade one of our wikis to 1.16.5 and see if that fixes the problem. If so, I will upgrade the others.
On Tue, 11 Oct 2011 22:40:22 +0000, Dan Nessett wrote:
On Tue, 11 Oct 2011 14:37:56 -0700, Brion Vibber wrote:
On Tue, Oct 11, 2011 at 10:17 AM, Dan Nessett dnessett@yahoo.com wrote:
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
Ok, my suspicion is on https://bugzilla.wikimedia.org/show_bug.cgi?id=28639, fixed in the 1.16.5 security release in May: < http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-
May/000098.html
It looks like there may be some cases where session expiration (or similar issues) might have left things in a state where the previous user's permissions got kept but the other info got thrown away. This would presumably allow edits etc to finish up, while recording them as not a user id.
-- brion
Thanks. I will upgrade one of our wikis to 1.16.5 and see if that fixes the problem. If so, I will upgrade the others.
Well, I upgraded one of our small wikis to 1.16.5. I don't know yet whether it fixes the login session problem, but it seems to create another problem. Atom feeds appear broken in 1.16.5. MW is inserting an extraneous line feed into the response to the atom feed request. On 1.16.2, the response begins (for Recent Changes atom feed):
0000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31 <?xml version="1 0010 2e 30 22 3f 3e 0a 3c 3f 78 6d 6c 2d 73 74 79 6c .0"?>.<?xml-styl 0020 65 73 68 65 65 74 20 74 79 70 65 3d 22 74 65 78 esheet type="tex 0030 74 2f 63 73 73 22 20 68 72 65 66 3d 22 68 74 74 t/css"
On 1.16.5 it begins:
0000 0a 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 .<?xml version=" 0010 31 2e 30 22 3f 3e 0a 3c 3f 78 6d 6c 2d 73 74 79 1.0"?>.<?xml-sty 0020 6c 65 73 68 65 65 74 20 74 79 70 65 3d 22 74 65 lesheet type="te 0030 78 74 2f 63 73 73 22 20 68 72 65 66 3d 22 68 74 xt/css"
Notice the LF at the beginning on 1.16.5. This causes most browsers to barf (interestingly, Safari 5.1 on a Mac doesn't). Here is the error message from opera (which is more informative than the one from firefox):
XML parsing failed
XML parsing failed: syntax error (Line: 2, Character: 0)
Reparse document as HTML Error: XML declaration not at beginning of document
Specification: http://www.w3.org/TR/REC-xml/
1: 2: <?xml version="1.0"?> 3: <?xml-stylesheet type="text/css" href="http://ec.citizendium.org/ skins/common/feed.css?270"?> 4: <feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"> 5: <id>http://ec.citizendium.org/wiki? title=Special:RecentChanges&feed=atom</id>
I have filed a bug (https://bugzilla.wikimedia.org/show_bug.cgi? id=31783). Perhaps this bug is related to 19055, but it wasn't clear from the description.
On Mon, Oct 17, 2011 at 3:54 PM, Dan Nessett dnessett@yahoo.com wrote:
Well, I upgraded one of our small wikis to 1.16.5. I don't know yet whether it fixes the login session problem, but it seems to create another problem. Atom feeds appear broken in 1.16.5. MW is inserting an extraneous line feed into the response to the atom feed request.
This is usually because of extra whitespace in LocalSettings.php or a custom extension file that has been manually edited. Check all your .php files for stray whitespace at the beginning or after a closing ?>
-- brion
On Mon, 17 Oct 2011 18:14:42 -0500, Brion Vibber wrote:
On Mon, Oct 17, 2011 at 3:54 PM, Dan Nessett dnessett@yahoo.com wrote:
Well, I upgraded one of our small wikis to 1.16.5. I don't know yet whether it fixes the login session problem, but it seems to create another problem. Atom feeds appear broken in 1.16.5. MW is inserting an extraneous line feed into the response to the atom feed request.
This is usually because of extra whitespace in LocalSettings.php or a custom extension file that has been manually edited. Check all your .php files for stray whitespace at the beginning or after a closing ?>
-- brion
That was it, thanks.
Getting back to the original problem, I am attempting to develop a way to force the problem to occur, so I can test whether 1.16.5 fixes the problem. On a development machine and a development wiki running 1.16.2, I changed the following values in php.ini:
session.gc_maxlifetime = 60 session.gc_probability = 100 session.gc_divisor = 100
From what I have read, I thought this would fire up the session garbage
collector on each access and timeout sessions after 60 seconds. It appears the latter is true, since if I log in (not setting "remember me"), edit a page, wait 60 seconds and try once again to edit the page, the latter is disallowed and the resulting response shows me logged off.
However, when I look at the sessions directory, the session created by my login is still there. Maybe I don't understand what the garbage collector does, but I assumed it would destroy the session record if its lifetime exceeded maxlifetime.
I know this is a PHP question, not a MW question, but I was hoping someone might fill me in. By the way, I am running PHP 5.3.4.
On Tue, Oct 18, 2011 at 11:36 AM, Dan Nessett dnessett@yahoo.com wrote:
From what I have read, I thought this would fire up the session garbage collector on each access and timeout sessions after 60 seconds. It appears the latter is true, since if I log in (not setting "remember me"), edit a page, wait 60 seconds and try once again to edit the page, the latter is disallowed and the resulting response shows me logged off.
However, when I look at the sessions directory, the session created by my login is still there. Maybe I don't understand what the garbage collector does, but I assumed it would destroy the session record if its lifetime exceeded maxlifetime.
I know this is a PHP question, not a MW question, but I was hoping someone might fill me in. By the way, I am running PHP 5.3.4.
Off the top of my head I'd guess this:
* around login time, a session is started: ** ID is generated: 123456789abcdef ** session cookie is sent to browser ** /path/to/sessions/123456789abcdef file is stored with the fresh data * after a while, some other request comes in ** session GC runs, removing the file /path/to/sessions/123456789abcdef * your first browser reconnects, providing a session ID key in its cookie ** server sees no session with that id, so establishes a new one ** /path/to/sessions/123456789abcdef file is stored with the fresh data
Possibly the request to trigger GC was also your own second request.
-- brion
On Wed, 19 Oct 2011 12:14:00 -0700, Brion Vibber wrote:
On Tue, Oct 18, 2011 at 11:36 AM, Dan Nessett dnessett@yahoo.com wrote:
From what I have read, I thought this would fire up the session garbage collector on each access and timeout sessions after 60 seconds. It appears the latter is true, since if I log in (not setting "remember me"), edit a page, wait 60 seconds and try once again to edit the page, the latter is disallowed and the resulting response shows me logged off.
However, when I look at the sessions directory, the session created by my login is still there. Maybe I don't understand what the garbage collector does, but I assumed it would destroy the session record if its lifetime exceeded maxlifetime.
I know this is a PHP question, not a MW question, but I was hoping someone might fill me in. By the way, I am running PHP 5.3.4.
Off the top of my head I'd guess this:
- around login time, a session is started: ** ID is generated:
123456789abcdef ** session cookie is sent to browser ** /path/to/sessions/123456789abcdef file is stored with the fresh data
- after a while, some other request comes in ** session GC runs,
removing the file /path/to/sessions/123456789abcdef * your first browser reconnects, providing a session ID key in its cookie ** server sees no session with that id, so establishes a new one ** /path/to/sessions/123456789abcdef file is stored with the fresh data
Possibly the request to trigger GC was also your own second request.
-- brion
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote:
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5 (and I presume in later releases). However, many wikis don't upgrade regularly. If their situation is like ours, there is a very small tech staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years before upgrading to 1.16.2). In addition, in our case we modify the standard distribution with a patchkit, so deploying a new release of MW requires applying that kit and testing before going live with it. This is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5. If they run up against the bug described in this thread and search Bugzilla for a fix, they won't find it. If I file a bug describing the problem and indicate it is fixed in 1.16.5, it provides those sites with knowledge about the problem without posting a question here or elsewhere.
On Sat, 29 Oct 2011 11:58:25 -0700, Dan Nessett dnessett@yahoo.com wrote:
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote:
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5 (and I presume in later releases). However, many wikis don't upgrade regularly. If their situation is like ours, there is a very small tech staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years before upgrading to 1.16.2). In addition, in our case we modify the standard distribution with a patchkit, so deploying a new release of MW requires applying that kit and testing before going live with it. This is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5. If they run up against the bug described in this thread and search Bugzilla for a fix, they won't find it. If I file a bug describing the problem and indicate it is fixed in 1.16.5, it provides those sites with knowledge about the problem without posting a question here or elsewhere.
- In x.y.z, the 'z' point releases contain bugfixes and security patches. The difference between x.y.1 and x.y.2 is tiny, there should be no major hassle in applying point releases. In fact you should be able to take the tarball for the point release you're currently on, the tarball for the new one, create a diff of them, and then apply that diff to your modified code to apply whatever fixes were added in the point release. Unless you touched code related to a bug there shouldn't really be any notable conflicts. - We don't make x.y.z.w releases, someone brought this bug up in 1.16 it was considered important enough for 1.16 users, and we released a .z point release to fix it. To 'release a fix' for this IS to release a .z point release, and that's already done.
I should also point out that sometime in November the 1.16 major is going to be considered obsolete and will no longer get ANY bug or security fixes.
Daniel Friesen wrote:
- In x.y.z, the 'z' point releases contain bugfixes and security patches.
The difference between x.y.1 and x.y.2 is tiny, there should be no major hassle in applying point releases. In fact you should be able to take the tarball for the point release you're currently on, the tarball for the new one, create a diff of them, and then apply that diff to your modified code to apply whatever fixes were added in the point release. Unless you touched code related to a bug there shouldn't really be any notable conflicts.
We even provide the upgrade in patch form, so they wouldn't even need to make the diff themselves.
On Sat, Oct 29, 2011 at 2:58 PM, Dan Nessett dnessett@yahoo.com wrote:
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote:
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5 (and I presume in later releases). However, many wikis don't upgrade regularly. If their situation is like ours, there is a very small tech staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years before upgrading to 1.16.2). In addition, in our case we modify the standard distribution with a patchkit, so deploying a new release of MW requires applying that kit and testing before going live with it. This is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5. If they run up against the bug described in this thread and search Bugzilla for a fix, they won't find it. If I file a bug describing the problem and indicate it is fixed in 1.16.5, it provides those sites with knowledge about the problem without posting a question here or elsewhere.
-- -- Dan Nessett
This thread has been educational on both the topic and patching conventions.
A well worded bug report, as you suggest, with a link back to this thread, would be a benefit without risk.
Please also provide this thread with a link to that bug report.
Thanks! --Fred
On Sat, 29 Oct 2011 16:10:51 -0400, Frederick Grose wrote:
On Sat, Oct 29, 2011 at 2:58 PM, Dan Nessett dnessett@yahoo.com wrote:
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote:
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5 (and I presume in later releases). However, many wikis don't upgrade regularly. If their situation is like ours, there is a very small tech staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years before upgrading to 1.16.2). In addition, in our case we modify the standard distribution with a patchkit, so deploying a new release of MW requires applying that kit and testing before going live with it. This is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5. If they run up against the bug described in this thread and search Bugzilla for a fix, they won't find it. If I file a bug describing the problem and indicate it is fixed in 1.16.5, it provides those sites with knowledge about the problem without posting a question here or elsewhere.
-- -- Dan Nessett
This thread has been educational on both the topic and patching conventions.
A well worded bug report, as you suggest, with a link back to this thread, would be a benefit without risk.
Please also provide this thread with a link to that bug report.
Thanks! --Fred
It appears I spoke too soon. The results I am getting from MW 1.16.5 are inconsistent. I invite someone else to try the following on a development installation of MW 1.16.5 and see if they get the results I do.
On a development machine (NOT a production machine):
+ Log out of the wiki, if you are currently logged in (or have checked the "remember me" box).
+ Make the following changes to php.ini:
- session.gc_probability = 100 - session.gc_divisor = 100 - session.gc_maxlifetime = 60 - session.save_path = <some directory writable by httpd>
+ Restart httpd
+ Delete all sessions in the session directory (i.e., session.save_path). This isn't strictly necessary, but it makes it easier to see how the session data are manipulated.
+ Access the wiki and login (DO NOT CHECK THE "REMEMBER ME" BOX). Move to a wiki page that you can edit. A new session file is created and it will look something like (assuming you logged on as the WikiSysop user):
wsUserID|i:1;wsToken|s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName| s:9:"WikiSysop";wsLoginToken|N;
+ Wait 60 seconds or more.
Edit the page by clicking on the edit tab. Make a change and save the page. You will see the message "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in." The session file will contain:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
Save the page again. This time it will work. The session data will not change. Now look at Recent Changes. The edit will show the successful edit assigned to an IP address not to the user.
If this result is reproducible, it indicates three problems. First, an edit is allowed even though the session has expired. Second, the edit is assigned to an IP address (which, actually, is a direct result of the first problem). Finally, I can continue to edit pages even though I am shown as logged out (the "log in/create account" message is shown at the top of the page).
This is exactly the same behavior for MW 1.16.2. Previously, I tried a different procedure on both MW 1.16.2 and MW 1.16.5 and MW 1.16.5 appeared to handle the problem correctly. However, it seems both releases behave the same when executing the procedure given above.
It would also be a good idea to check against 1.17.0, 1.18br and 1.19trunk and see if this issue has been fixed somewhere down the pipeline.
On Mon, Oct 31, 2011 at 3:30 PM, Dan Nessett dnessett@yahoo.com wrote:
On Sat, 29 Oct 2011 16:10:51 -0400, Frederick Grose wrote:
On Sat, Oct 29, 2011 at 2:58 PM, Dan Nessett dnessett@yahoo.com wrote:
On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote:
Dan Nessett wrote:
After testing, it appears moving to 1.16.5 solves the problem. Should I file a bug against 1.16.2 and mention it is fixed in 1.16.5? This might help those who run 1.16.x, x < 5 if, if they run into the same problem
Such bug wouldn't get any action. Bugs in 1.16.x are fixed in a new release 1.16.y (y > x). This is already fixed, Nothing we can do to solve people in old versions.
I think you have missed the point. The bug is already fixed in 1.16.5 (and I presume in later releases). However, many wikis don't upgrade regularly. If their situation is like ours, there is a very small tech staff and it is unrealistic to upgrade often (we ran 1.13.2 for 3 years before upgrading to 1.16.2). In addition, in our case we modify the standard distribution with a patchkit, so deploying a new release of MW requires applying that kit and testing before going live with it. This is not a trivial amount of work.
Consequently, I would guess there are many wikis running 1.16.x, x < 5. If they run up against the bug described in this thread and search Bugzilla for a fix, they won't find it. If I file a bug describing the problem and indicate it is fixed in 1.16.5, it provides those sites with knowledge about the problem without posting a question here or elsewhere.
-- -- Dan Nessett
This thread has been educational on both the  topic and patching conventions.
A well worded bug report, as you suggest, with a link back to this thread, would be a benefit without risk.
Please also provide this thread with a link to that bug report.
Thanks! Â Â Â Â --Fred
It appears I spoke too soon. The results I am getting from MW 1.16.5 are inconsistent. I invite someone else to try the following on a development installation of MW 1.16.5 and see if they get the results I do.
On a development machine (NOT a production machine):
- Log out of the wiki, if you are currently logged in (or have checked
the "remember me" box).
- Make the following changes to php.ini:
- session.gc_probability = 100  - session.gc_divisor   = 100  - session.gc_maxlifetime = 60  - session.save_path = <some directory writable by httpd>
Restart httpd
Delete all sessions in the session directory (i.e., session.save_path).
This isn't strictly necessary, but it makes it easier to see how the session data are manipulated.
- Access the wiki and login (DO NOT CHECK THE "REMEMBER ME" BOX). Move to
a wiki page that you can edit. A new session file is created and it will look something like (assuming you logged on as the WikiSysop user):
wsUserID|i:1;wsToken|s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName| s:9:"WikiSysop";wsLoginToken|N;
- Wait 60 seconds or more.
Edit the page by clicking on the edit tab. Make a change and save the page. You will see the message "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in." The session file will contain:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
Save the page again. This time it will work. The session data will not change. Now look at Recent Changes. The edit will show the successful edit assigned to an IP address not to the user.
If this result is reproducible, it indicates three problems. First, an edit is allowed even though the session has expired. Second, the edit is assigned to an IP address (which, actually, is a direct result of the first problem). Finally, I can continue to edit pages even though I am shown as logged out (the "log in/create account" message is shown at the top of the page).
This is exactly the same behavior for MW 1.16.2. Previously, I tried a different procedure on both MW 1.16.2 and MW 1.16.5 and MW 1.16.5 appeared to handle the problem correctly. However, it seems both releases behave the same when executing the procedure given above.
-- -- Dan Nessett
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Confirmed in trunk.
I detail what I think is happening:
- Access the wiki and login (DO NOT CHECK THE "REMEMBER ME" BOX). Move to
a wiki page that you can edit. A new session file is created and it will look something like (assuming you logged on as the WikiSysop user):
wsUserID|i:1;wsToken|s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName| s:9:"WikiSysop";wsLoginToken|N;
You get a normal session.
- Wait 60 seconds or more.
The session expires.
Edit the page by clicking on the edit tab.
This step is interesting, since the session is expired but you are treated as logged in. Maybe php is accepting the session, and then deleting it right away.
Make a change and save the page. You will see the message "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in."
This is normal since you are trying to send a logged-in page as anonymous (token mismatch => that message).
The session file will contain:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
Seems the wiki created a new session with the same name. Or perhaps it renewed only those two fields.
Save the page again. This time it will work. The session data will not change. Now look at Recent Changes. The edit will show the successful edit assigned to an IP address not to the user.
You were now an IP, so it is normal that it produces the log as IP.
If this result is reproducible, it indicates three problems.
First, an edit is allowed even though the session has expired.
As far as you allow anoynmous editing, this is not a bug. There's no way to differenciate that. Unless we check that if there's an unknown session in a cookie to show a big warning and not allow him to send anything.
Second, the edit is assigned to an IP address (which, actually, is a direct result of the first problem).
As far as you pressed 'Save' when the header showed you as a IP, this is normal behavior.
Finally, I can continue to edit pages even though I am shown as logged out (the "log in/create account" message is shown at the top of the page).
As far as you allow anoynmous editing, this is normal behavior.
I disagree on where are the bugs, but you are right that there's somehting strange going on with the session.
On Mon, 31 Oct 2011 23:57:59 +0100, Platonides wrote:
Confirmed in trunk.
I detail what I think is happening:
- Access the wiki and login (DO NOT CHECK THE "REMEMBER ME" BOX). Move
to a wiki page that you can edit. A new session file is created and it will look something like (assuming you logged on as the WikiSysop user):
wsUserID|i:1;wsToken|
s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName|
s:9:"WikiSysop";wsLoginToken|N;
You get a normal session.
- Wait 60 seconds or more.
The session expires.
Edit the page by clicking on the edit tab.
This step is interesting, since the session is expired but you are treated as logged in. Maybe php is accepting the session, and then deleting it right away.
Make a change and save the page. You will see the message "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in."
This is normal since you are trying to send a logged-in page as anonymous (token mismatch => that message).
The session file will contain:
wsUserID|i:1;wsUserName|s:9:"WikiSysop";
Seems the wiki created a new session with the same name. Or perhaps it renewed only those two fields.
Save the page again. This time it will work. The session data will not change. Now look at Recent Changes. The edit will show the successful edit assigned to an IP address not to the user.
You were now an IP, so it is normal that it produces the log as IP.
If this result is reproducible, it indicates three problems.
First, an edit is allowed even though the session has expired.
As far as you allow anoynmous editing, this is not a bug. There's no way to differenciate that. Unless we check that if there's an unknown session in a cookie to show a big warning and not allow him to send anything.
Second, the edit is assigned to an IP address (which, actually, is a direct result of the first problem).
As far as you pressed 'Save' when the header showed you as a IP, this is normal behavior.
Finally, I can continue to edit pages even though I am shown as logged out (the "log in/create account" message is shown at the top of the page).
As far as you allow anoynmous editing, this is normal behavior.
I disagree on where are the bugs, but you are right that there's somehting strange going on with the session.
I should have mentioned that our wikis are set up so anonymous users can only read pages. You must be logged in to edit pages. However, when I set up the development wiki for the above test, I failed to set up permissions in that way. I will do so and get back to this thread with the results.
I have filed a bug - https://bugzilla.wikimedia.org/show_bug.cgi?id=32122
On Tue, 01 Nov 2011 17:38:41 +0000, Dan Nessett wrote:
I should have mentioned that our wikis are set up so anonymous users can only read pages. You must be logged in to edit pages. However, when I set up the development wiki for the above test, I failed to set up permissions in that way. I will do so and get back to this thread with the results.
I have filed a bug - https://bugzilla.wikimedia.org/show_bug.cgi?id=32122
I have run the test on wikis with permissions set as indicated above. In both MW 1.16.2 and MW 1.16.5, the following message is displayed.
"You do not have permission to edit this page, for the following reason:
The action you have requested is limited to users in one of the groups: Users, Administrators.
You can view and copy the source of this page:"
So, I cannot reproduce the bug I am chasing.
I should mention that the motivation for this line of investigation arose from an intermittent problem on our wikis (which run 1.16.2). Occasionally edit records in Recent Changes would show up with the IP address of the user making the edit. This should never happen on our wikis since, as stated previously, only logged in users should have page edit privileges.
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.
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";
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.
I have updated the bug report to reflect the current state of understanding about the problem.
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
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.
On Wed, Nov 9, 2011 at 11:56 AM, Dan Nessett dnessett@yahoo.com wrote:
[snip] 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.
What problems remain other than the ones I noted previously as being known problems or expected behavior?
-- brion
On Wed, 09 Nov 2011 13:20:47 -0800, Brion Vibber wrote:
On Wed, Nov 9, 2011 at 11:56 AM, Dan Nessett dnessett@yahoo.com wrote:
[snip] 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.
What problems remain other than the ones I noted previously as being known problems or expected behavior?
-- brion
Documented in the bug report (comment 4).
On Wed, Nov 9, 2011 at 2:50 PM, Dan Nessett dnessett@yahoo.com wrote:
What problems remain other than the ones I noted previously as being known problems or expected behavior?
Documented in the bug report (comment 4).
Ok so to confirm:
* This is primarily about the bug we told you should be fixed by the session security fix in 1.16.5 if it's happening to you * You can't reproduce it on 1.16.5, but also can't reproduce it on 1.16.2 anymore? * You're trying to reproduce it exactly on 1.16.2 so you personally can confirm it is indeed fixed in 1.16.5 * The loads of details about session info and behavior are just for you to log what's going on so you can identify the bug when you see it, and don't indicate any new issues.
I've changed the summary on the bug to indicate that it's an old bug believed to be fixed in 1.16.5, and not something new or remaining that would require additional fixes.
-- brion
On Wed, 09 Nov 2011 15:26:07 -0800, Brion Vibber wrote:
On Wed, Nov 9, 2011 at 2:50 PM, Dan Nessett dnessett@yahoo.com wrote:
What problems remain other than the ones I noted previously as being known problems or expected behavior?
Documented in the bug report (comment 4).
Ok so to confirm:
- This is primarily about the bug we told you should be fixed by the
session security fix in 1.16.5 if it's happening to you * You can't reproduce it on 1.16.5, but also can't reproduce it on 1.16.2 anymore?
- You're trying to reproduce it exactly on 1.16.2 so you personally can
confirm it is indeed fixed in 1.16.5
- The loads of details about session info and behavior are just for you
to log what's going on so you can identify the bug when you see it, and don't indicate any new issues.
I've changed the summary on the bug to indicate that it's an old bug believed to be fixed in 1.16.5, and not something new or remaining that would require additional fixes.
-- brion
That is a fair summary with some minor corrections.
+ The problem originally documented occurred on two of our wikis. The evidence of it exists in their recent changes logs. However, I have been unable to develop a procedure that will reliably reproduce the error. It only occurs intermittently on the live wikis running 1.16.2. I moved one of those wikis to 1.16.5 and so far the problem has not reoccurred.
+ I have been able to develop procedures that demonstrate other problems with session management on 1.16.2, but so far those procedures do not show a problem on 1.16.5. Since these problems arise intermittently, this does not demonstrate categorically the absence of the problems on 1.16.5. So, while it is probably safe to assume 1.16.5 fixes these problems, I cannot state that with 100% certainty.
+ I am trying to reproduce the original problem exactly on 1.16.2 not just for me personally. Documenting a procedure that reproduces the problem helps others who run up against a session related problem to determine if it is the same problem described in this bug ticket. So, the detail is intended to help not only me, but others who run wikis experiencing session management problems.
+ The ticket does indicate at least on new problems that probably requires attention. Specifically, when a session times out and the user accesses the wiki, the login status is incorrectly shown at the top of the page until a additional page access (e.g., after a browser refresh). I believe you have described how this problem might be solved.
Dan
On Wed, 09 Nov 2011 15:26:07 -0800, Brion Vibber wrote:
On Wed, Nov 9, 2011 at 2:50 PM, Dan Nessett dnessett@yahoo.com wrote:
What problems remain other than the ones I noted previously as being known problems or expected behavior?
Documented in the bug report (comment 4).
Ok so to confirm:
- This is primarily about the bug we told you should be fixed by the
session security fix in 1.16.5 if it's happening to you * You can't reproduce it on 1.16.5, but also can't reproduce it on 1.16.2 anymore?
- You're trying to reproduce it exactly on 1.16.2 so you personally can
confirm it is indeed fixed in 1.16.5
- The loads of details about session info and behavior are just for you
to log what's going on so you can identify the bug when you see it, and don't indicate any new issues.
I've changed the summary on the bug to indicate that it's an old bug believed to be fixed in 1.16.5, and not something new or remaining that would require additional fixes.
-- brion
This morning I reproduced the problem described in comment 4 of the bug report in 1.16.5. Details are given there in comment 11.
On Wed, 09 Nov 2011 13:20:47 -0800, Brion Vibber wrote:
On Wed, Nov 9, 2011 at 11:56 AM, Dan Nessett dnessett@yahoo.com wrote:
[snip] 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.
What problems remain other than the ones I noted previously as being known problems or expected behavior?
-- brion
I have figured out a way to reliably reproduce the problem described in comment 12 of the bug ticket (https://bugzilla.wikimedia.org/show_bug.cgi? id=32122). Details are in comment 13. This is not the original problem, but analyzing it may provide some hints as to the cause of original problem.
On Tue, 11 Oct 2011 14:37:56 -0700, Brion Vibber wrote:
On Tue, Oct 11, 2011 at 10:17 AM, Dan Nessett dnessett@yahoo.com wrote:
Thanks for your reply and for the clarification about sessions not associating with IP addresses. However, it seems unlikely that session expiration is the problem.
Our wikis require login before users can do anything other than view pages. However, when the situation I described previously occurs, the user is able to edit pages and do anything else his permissions allow when logged in. The problem appears to have something to do with the way IP addresses are mapped to user names by the logging logic. That is, the session is still active, but when entries are made in the logs, the username is replaced either by the IP address of the request or by the generic identifier "anonymous" (different behavior on different wikis - probably a configuration issue, which I am investigating).
Ok, my suspicion is on https://bugzilla.wikimedia.org/show_bug.cgi?id=28639, fixed in the 1.16.5 security release in May: < http://lists.wikimedia.org/pipermail/mediawiki-announce/2011-
May/000098.html
It looks like there may be some cases where session expiration (or similar issues) might have left things in a state where the previous user's permissions got kept but the other info got thrown away. This would presumably allow edits etc to finish up, while recording them as not a user id.
-- brion
I have verified that this problem is fixed in 1.16.5. See comment 19 of bug 32122 (https://bugzilla.wikimedia.org/show_bug.cgi?id=32122). I have closed the bug ticket with a status of resolved/fixed.
mediawiki-l@lists.wikimedia.org