On Mon, 10 Oct 2011 12:44:57 -0700, Brion Vibber wrote: maxlifetime configuration.html#suhosin.session.checkraddr 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). -- -- Dan Nessett

On Tue, Oct 11, 2011 at 10:17 AM, Dan Nessett &lt;dnessett(a)yahoo.com&gt; wrote: 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 22:40:22 +0000, Dan Nessett 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. 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&amp;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. -- -- Dan Nessett

On Mon, 17 Oct 2011 18:14:42 -0500, Brion Vibber wrote: 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 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. -- -- Dan Nessett

On Wed, 19 Oct 2011 12:14:00 -0700, Brion Vibber 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 -- -- Dan Nessett

On Fri, 28 Oct 2011 23:30:10 +0200, Platonides wrote: 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

Daniel Friesen wrote: We even provide the upgrade in patch form, so they wouldn't even need to make the diff themselves.

On Sat, 29 Oct 2011 16:10:51 -0400, Frederick Grose wrote: 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

Confirmed in trunk. I detail what I think is happening: You get a normal session. The session expires. 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. This is normal since you are trying to send a logged-in page as anonymous (token mismatch => that message). Seems the wiki created a new session with the same name. Or perhaps it renewed only those two fields. You were now an IP, so it is normal that it produces the log as IP. 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. As far as you pressed 'Save' when the header showed you as a IP, this is normal behavior. 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 Tue, 01 Nov 2011 17:38:41 +0000, Dan Nessett wrote: 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. -- -- Dan Nessett

On Tue, 01 Nov 2011 12:05:57 -0700, Brion Vibber wrote: s:32:"0ff5b9ecf52077fb05cc74731f13ba2b";wsUserName| 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

On Wed, 09 Nov 2011 13:20:47 -0800, Brion Vibber wrote: Documented in the bug report (comment 4). -- -- Dan Nessett

On Wed, 09 Nov 2011 15:26:07 -0800, Brion Vibber wrote: 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 -- -- Dan Nessett

On Wed, 09 Nov 2011 13:20:47 -0800, Brion Vibber wrote: 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. -- -- Dan Nessett