Probably a bad caching proxy. Are the two of you on the same
ISP / school / work web proxy perhaps?

locutus wrote:

No, different countries.

locutus wrote:

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.

ayg wrote:

*** Bug 6969 has been marked as a duplicate of this bug. ***

ayg wrote:

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.

locutus wrote:

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.

locutus wrote:

(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.

robchur wrote:

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

Schwalbe.Wikipedia wrote:

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.

wiki.bugzilla wrote:

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

ayg wrote:

*** Bug 7103 has been marked as a duplicate of this bug. ***

ayg wrote:

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).

ayg wrote:

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é/Portal/Archivo/Técnica/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.

locutus wrote:

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?).

locutus wrote:

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.

tderouin wrote:

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.

thogol wrote:

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.

locutus wrote:

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.

tderouin wrote:

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:
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.

tderouin wrote:

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.

locutus wrote:

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.

ayg wrote:

New sighting on the Japanese Wikipedia:
http://lists.wikimedia.org/pipermail/wikitech-l/2007-January/029303.html

wiki_tomos wrote:

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:削除依頼/駐車場綜合研究所&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:Σ６４
(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.

scotteaux wrote:

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.

fearow00 wrote:

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.

fearow00 wrote:

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);

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).

MediaWiki wrote:

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

mattj wrote:

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