Last modified: 2014-11-18 18:07:16 UTC
First of all, I'll leave the severity and priority fields unchanged because I didn't take the time review this Bugzilla policy, however this bug should at least be considered critical though as of now I'm still unable to repeatedly reproduce it. Every now and then on the above installation of Mediawiki (1.6.7 straight of the box) I've found myself logged in as someone else as seen in the following screen shots: http://img483.imageshack.us/img483/6339/umm3ez.jpg http://img163.imageshack.us/img163/5152/umm24jw.jpg These encourages happen in what appears to be a random fashion and as of now cannot be repeatedly reproduced, at least by me. From the brief discussion we had on the Wiki it appears only me and another user are effected. This seems to happen only when I'm logged already in and seems to stick across multiple pages and will only return to normal if I log off again. I'm able to do changes on his account and post as him. (Keep in mind that when I lop on again, I'm back at my normal account) One thing I should mention is that the wiki seems to have a cache problem, how genuine this problem is though I'm not sure. (As seen below) http://img509.imageshack.us/img509/1787/umm39bt.jpg So far I've ignored this message and everything as been working as it should. The user I'm logged on as reports that he finds himself logged in as me as well. For now I'm not sure if this effected anyone else due to the fact that it isn't a very active wiki, and most people won't even notice should they'll have the same problem though you'll have to remember that myself and the other user only get logged in as each other and not as someone else. Keep in mind that this happened when I returned to the wiki after a period of time and during normal operation on the board. Though I don't remember if it was after a long pause or not. I have cookies enabled and the "remember me" option turned on. If you need any more information then please contact me. P.S. I apologize if I'm posting a duplicate, I wasn't able to find a similar bug.
Probably a bad caching proxy. Are the two of you on the same ISP / school / work web proxy perhaps?
No, different countries.
Same person just reported that he was just logged in as someone else beside me, I should mention that the site I'm talking about was a 1.5.x mediwiki upgraded to 1.6.7. I'm trying to find out if more users are effected by this on the wiki.
*** Bug 6969 has been marked as a duplicate of this bug. ***
Some possibly useful datapoints from the other bug: (bug 6969 comment #2) > [[hu:User:Vince]] reported the same on huwiki a couple of hours ago. The links > to the preferences and watchlist were missing from the personal toolbar, > everything else was there. He remained logged in as another user after following > a link. I'll try to get more details. The bug reporter from bug 6969 gave dewiki as the link, so apparently that's two or more independent occurrences on at least two different WMF sites.
Might as well mention that we're still getting the same bug though it seems to occur more frequently now. Though I did notice a pattern, it seems the user gets logged in as someone else when the other user logs in at the same time the user issued a request from the server. As I said, it sounds like a cache problem to me.
I copy my comment from bug 6969: (In reply to comment #1) > did you just see a page with anotehr user's name on it, or where you > actually able to edit using the identity of this user? When navigating the wiki > at random, do you stay logged in as "the other user"? > > In case this happens again, please record the following, if you can: the IP > address you got for the wiki site, the HTML page itself, the HTTP response > headers and any cookies you have for the wiki's site. If the log in as the foreign user is persistent during navigation (as indicated by teh reported of bug 6969), or even allows editing as that user (don't know if it does), then it's *not* a caching issue but a *serious* bug. I would be especiall interested to know what the user name cookie looks like when this happens.
(In reply to comment #7) > If the log in as the foreign user is persistent during navigation (as indicated > by teh reported of bug 6969), or even allows editing as that user (don't know if > it does), then it's *not* a caching issue but a *serious* bug. I would be > especiall interested to know what the user name cookie looks like when this happens. Then I can tell how it works here, sometimes you're able to post as that foreign user, from personal experience I was able to alter the foreign user watch list, change his personal configuration and I believe that if I tried I would have been able to change his password. Keep in mind that our users complained that they were sometimes logged in as the admin user. Again, I can confirm you that it only happened when that same user was accessing the site at the same time. Keep in mind that sometimes when you're logged in as someone else all it takes is to refresh the page to return to your own user session. I'll try giving you the information you requested as soon as possible.
The relevant function appears to be User::loadFromSession - there, the user id/name from cookie and session could be compared, and if they mismatch, this should be logged and the session terminated. I'd hope that could give us some way to track down the problem - in case it's not purely caching. I'm a bit scared to touch that code, though - I don't fully understand the implications.
I'm inclined to agree that we need to start logging this. If people are being logged on as others, and the session is persisting, then that's a critical security flaw and we need to find it and fix it, fast.
For reference, two threads on the dewiki pump: http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=20433833#Bearbeitung_nicht_von_mir http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia&oldid=20433833#Ohne_Account_eingeloggt.3F
A similar thing happened to me on de: at about 21 Aug 09:30 (CEST). See http://de.wikipedia.org/wiki/Wikipedia_Diskussion:Administratoren/Notizen#Sicherheitsl.C3.BCcke.3F (with screenshot) for details. I was not able to edit with this account but do not use the "remember me" option. I never saw the cache problem message mentioned above.
Just for the case the reporter's location may be of interest to narrow the problem down: There was another report on 8th of august by a german IP (Mac user), see: http://www.mediawiki.org/w/index.php?title=Project:Support_desk&oldid=37786#Automatically_logged_in_as_an_unknown_user ---- Addition to #12 (permanent link): http://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Administratoren/Notizen&oldid=20518732#Sicherheitsl.C3.BCcke.3F
*** Bug 7103 has been marked as a duplicate of this bug. ***
Suggestion from Nick Jenkins on Wikitech-l <http://mail.wikipedia.org/pipermail/wikitech-l/2006-August/038270.html>: > I've seen the same general type of problem (PHP app that confuses users with no > immediately obvious explanation) happen exactly twice in a period of 6 years on > some of my (non-MediaWiki) apps. > > I'm not 100% sure why, and it's so rare that it's _extremely_ hard to be sure, > but my working theory is that by pure random fluke two session_id strings or > two session file names/keys have clashed, resulting in user identity getting > confused. > > I recall reading an article in PHP|Architect around a year ago about how you > could store the first parts of the user's IP address + the usual session_id > stuff to lessen the chance of something like this (not eliminate it however, > since you could still have a large proxy supporting many users, or an > especially active subnet, and potentially have the same thing) + other various > tricks to switch the session_id if it looks like someone is trying to spoof it > or if there's an accidental clash. > > As a disclaimer, I have only very superficially scanned some of MediaWiki's > session handling code (so it could already have these guards, I honestly don't > know), but *maybe* it's something like this? That's my first thought, anyway. > > Certainly the number of WP users is much higher, so the chances of clashes > happening presumably are correspondingly greater too. (i.e. on a long enough > time-scale, and with enough permutations, the statistically improbable becomes > probable).
But Timwi gives good reasons for why that can't be the case: <http://mail.wikipedia.org/pipermail/wikitech-l/2006-August/038302.html>
Reported at es: Village Pump. User Satesclop appearing logged as Ketamino. Cookies were disabled. He then brwosed to RecentChanges and "the odd thing" disappeared: http://es.wikipedia.org/wiki/Wikipedia:Caf%C3%A9/Portal/Archivo/T%C3%A9cnica/2006/08#Algo_incre.C3.ADble
Uh, with cookies disabled, login wouldn't be possible at all...
His words: "Not only it, but i also had cookies disabled". I guess he meant he hadn't 'Remember me' feature enabled... :?
This may be related to the Squid 2.6 ETag issue. If so, new cases _ought_ not to show up since yesterday.
Not sure if this helps anyone but the cookies remain the same even when you're logged in as someone else, they still point towards your original user even while you're logged in as someone else. Tested with IE6, 1.6.7. The other user details persist even while switching pages, and attempting to access the user configuration page. I'll try to reproduce it with a more sane browser if I'll get the same problem again. (Keep in mind, I'm talking about a local installation and /not/ the official wikipedia servers.
Then it's an intermal wiki problem, not related to the Squids (i assume you're only using mysql, php, mediawiki & a browser to loaclhost, without more advanced cahcing systems, right?).
MediaWiki: 1.6.7 PHP: 4.3.8 (apache2handler) MySQL: 4.1.11 I'm not sure about the latter though, we're talking about a mediawiki installation that is accessible though the link I posted above.
We are also experiencing this bug at wikiHow, using MW 1.6.7. It does not appear to be a problem related to caching since the affected users can actually edit pages under the username they appear to be logged in as. So far, only 2 people can reproduce the problem.
Maybe the same reason: On de.wikipedia, a user denies to have edited an article. He occurs in the history of the article, but on Special:Contributions the article does not occur. I guess, another user was logged in as him and edited there without noticing that he did that not as himself. Probably the database added the edits to the contributions of the one who really did the edits, but saved the wrong account in the history. Grtx.
Thomas: if that's true, please email details directly to me IMMEDIATELY.
Maybe I didn't mention this before but people are able to edit articles and change the user settings while logged as someone else. In fact the sessions remains persistent until you log off. The problem seems more consistent when using IE 6, at least from my personal experience. There was a time I was able to reproduce it every time I visited the Wiki. Perhaps when another used was preforming an action on the Wiki at the same time?
Locutus: please upgrade to 1.8.2, flush any proxy caches, and see if the issue persists. I have a theory that this issue may have been caused by something which has been changed, but since we cannot reproduce it we have no way to know without testing.
Hey Brion, Is this something I could make a patch for to test out on 1.6.7? I could put it in place, and ask anyone who experiences the problem again to let me know - our users seem to run into it reliably. Upgrading is a huge process for us unfortunately, and takes a few weeks to do. Thanks.
Here's the changes on trunk: r1=16475&r2=16649&view=patch">http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/RawPage.php?r1=16475&r2=16649&view=patch I haven't tested it on 1.6 but it does appear to apply cleanly.
Hi Brion, Thanks. This patch seems to only affect situations where action=raw, correct? Our users are having this problem just viewing pages normally, and can actually edit articles while logged in as other users. I don't think anyone views the raw version of our pages at all, logged in or not logged in.
We can't update to 1.8.*, we don't have access to PHP5.
Travis, I'm aware of what the patch changes, which is exactly why I recommend it to you. If you like I can explain this in detail offline. Locutus: PHP 5 is available for free under an open source license, and is already present on countless thousands of hosting providers as well as anywhere you choose to install it. If you choose to stick with older, buggier software that's your choice.
New sighting on the Japanese Wikipedia: http://lists.wikimedia.org/pipermail/wikitech-l/2007-January/029303.html
More instances are reported on Japanese Wikipedia. http://ja.wikipedia.org/wiki/User:Trashwriter reported that account mix-up happened to him again. The following edit was attributed to user:Gwkaakun, though it was his own. http://ja.wikipedia.org/w/index.php?title=Wikipedia:%E5%89%8A%E9%99%A4%E4%BE%9D%E9%A0%BC/%E9%A7%90%E8%BB%8A%E5%A0%B4%E7%B6%9C%E5%90%88%E7%A0%94%E7%A9%B6%E6%89%80&diff=10376487&oldid=10374004 Trashwriter also reports that there are more than 10 edits in his contribution records that are not his own. Also, http://ja.wikipedia.org/wiki/User:%CE%A3%EF%BC%96%EF%BC%94 (I will call him Sigma64 hereafter) reported that he experienced this glitch four times in the past 2 days. He said one image was posted under his username, but it is done by someone else. He considers this problematic, though he does not mind to be attributed for edits on regular articles. He requested the image to be deleted. He said that he was once logged on as User:Annet152. User:Annet152, when asked by User:Sigma64, said that he, too, was affected by the glitch. User:Sigma64 thought User:Annet152 was the one who posted the image to Wikipedia, but User:Annet152 said he did not do that. ---- User:Trashwriter reported his environment when the bug took effect: -Windows XP -IE7.0.5730.11 -ISP: airH" with no proxy. I think airH" is a mobile internet service that typically routes packets from a computer (or other device) to a mobile phone, which in turn send it to the mobile phone company offering the service, and then to an ISP's dual-up service that the user is subscribed to. He saved a copy of cookie when the bug took effect, as requested by a developer. He wants to know how to send it, and to whom.
I made some more tweaks in r19795 which may or may not affect this issue; said issue also may or may not be related to some temporary squid problems we had a week or so ago, which may or may not be completely resolved and may or may not have left some bad cached entries which may or may not still have some effect. Live code hasn't been updated yet, so give it some time.
I would like to report a possible case of someone being logged in as me. My username on the english wikidpedia is "Scotteaux" and on March 19 there was a contribution made with my username to "Private university." I am certain that I did not make this change. I only access wikipedia from home and so I can't imagine how anyone would have been able to have access to my account.
I've been reading through the code, and this definately sounds like session collisions - I met this problem on a previous PHP application I was running. A simple way to fix should be to store the client's IP in a session variable, then in User::loadFromSession compare the session IP to the clients IP. Another option would be to salt the session key with the IP - however then you still have a chance of collision. This would also increase security, however it would mess up users whos IP changes while on the internet - as far as I know, this would be very hard to do under TCP/IP, and should not happen -Matt
Roaming IPs are not uncommon with AOL, which uses a very ugly proxy system.
What about storing a "session key" in the user table, generated from something like this: $sesskey = md5($_REQUEST['REMOTE_ADDR']) . md5($user->name . $user->id); NOTE: I couldnt remember the exact feilds for name and id, but those seem accurate enough. Store it in a cookie, then on pageload, compare the session key of the cookie to the one in the DB. If its incorrect, log the user out. The key would be updated in the DB on login. The only problem with this is the user cannot be logged in from two IP addresses at once - this is added security anyway, so no problem. The key may have to have more information to make it harder for collisions, but should be fine.
It would also conflict with the 'Remember me' option, failing to keep the used logged if it changes ips since first login (ie. a period of days).
Just as a general comment, IP salting would be rather frustrating, since I often change locations in the span of a day with the same computer. Having to log back into the software would definitely disrupt routine, in my case.
It would help a lot if loadFromSession() matched the user name to the ID
Doesn't it do so on line 846?
(In reply to comment #44) > Doesn't it do so on line 846? > I mean checking the cookie username to the session username value
Cookie user ID checked in r42040 to limit accidents like the above
