Page MenuHomePhabricator

Using two accounts can lead to login failure with "Session ID/User mismatch"
Open, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:

  • You get logged out

What should have happened instead?:

  • You stay logged in until you close your browser window

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

  • Tried on Edge a couple times using the non-admin account NovemBot
  • No 2FA on this account

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@matmarex also tried to reproduce without too much luck. This may be related to T372702 but we're not sure.

@Novem_Linguae could you try to narrow down how to replicate this issue? Is it just that one account that is facing this issue? What about other browsers?

Sure. I did some testing just now...

  • ✅ I was able to replicate this with a different account (NovemTest1)
  • ✅ I was able to replicate this on a different wiki (enwiki)
  • ❌ I was NOT able to replicate this in a different browser (Firefox)
  • ❌ I was NOT able to replicate this ticking the "Keep me logged in" check box (as expected, mentioned in the original ticket)

Seems like this is a Chromium-only bug.

I still can't reproduce.

Logs for the NovemTest1 enwiki login attempt: https://logstash.wikimedia.org/goto/4e96442182f4358d1f28acf8f4f7d7df

There's a lot of Metadata merge failed / Key "CentralAuthSource" changed warning messages, which are the reason why you immediately become logged out again. I don't see what causes them though. It's supposed to only happen if you actually try to log out, or if your cookies are somehow messed up.

You probably already have the https://wikitech.wikimedia.org/wiki/WikimediaDebug browser extension installed. Can you try enabling it, checking the "Verbose log" checkbox, and then doing the reproduction steps again? (Please uncheck it afterwards, the verbose logs are really verbose.)

Also, have you been testing this in a private/incognito browser window, or not? If not, can you try that and see if the issue still occurs? (That would indicate your cookies are in fact somehow messed up.)

No private mode, yes verbose debugging

Sure. I turned on verbose logging and tried the NovemTest1 logins again. The first time I was unable to reproduce. The second time I was able to reproduce. So there should be some verbose logs of the bug now.

This is the first time that the test steps have been intermittent for me. Before this attempt they were always consistent.

Yes private mode, no verbose debugging

I tried 5 times to reproduce this in Edge InPrivate mode, with 2 different accounts. Was unable to reproduce.

Nice, thank you, I've got what I was looking for:

CentralAuthSessionProvider::provideSessionInfo: Session ID/User mismatch. Possible session collision. Expected: NovemTest1; actual: Novem Linguae
CentralAuthSessionProvider::provideSessionInfo: Session ID/User mismatch. Possible session collision. Expected: Novem Linguae; actual: NovemTest1

So I guess this requires logging out of an account and into a different one. We must be failing to clear some cookies that confuse MediaWiki after the next login. Someone should be able to reproduce with a bit of effort now.

Not sure if this could have been the same problem before you created the test account, but maybe you logged in as NovemBot or something?

NovemTest1 was created in 2022. NovemBot was created in 2021. None of these were recently created.

I typically keep my Chrome logged into Novem Linguae (main browser), and my Edge logged out or logged into secondary accounts (testing browser). However both browsers have probably logged into all the accounts in my sockfarm at one point or another.

Moving to current sprint as this is could be related to the ticket we're currently working on - T372702.

This might be unrelated, but I experienced something similar to this on wikidata.org last week.

I was centrally logged-in. I appeared logged-out on wikidata.org. Clicking "Log in" did not log me in automatically. Filing in the form led to an error message about sesssion loss.

https://logstash.wikimedia.org/goto/6c4083048799b664a144101789eeb42e

  • [session] [INFO] Failed to load session, unpersisting
  • [session] [WARNING] Session "{session}": Metadata merge failed: {exception}
  • [CentralAuth] [INFO] Expected key global:central-login-complete-token:centralauth:*** found.
  • [authevents] [INFO] Central login attempt

Logging out and then logging into a different account works fine for me.

Possible session collision is logged when the username in the centralauth_User cookie mismatches the username stored in the session entry identified by the centralauth_Session cookie. (The code refers to T21158: Logged in as another user but it seems like the check was added without an attempt to figure out what was going on there.) These are cookies on .wikipedia.org so they can easily be changed by a different browser window, but they are always written or set together. Maybe at the browser implementation level cookies are written to the store one by one so there is a tiny interval when they are inconsistent? Seems far-fetched. Other than that, I can't imagine how they would end up with inconsistent values.

Tgr renamed this task from Logging in on testwiki without the "keep me logged in" tick box is broken to Using two accounts can lead to login failure with "Session ID/User mismatch".Jan 9 2025, 7:27 PM
Tgr removed Tgr as the assignee of this task.Jan 12 2025, 4:05 PM
Tgr moved this task from In progress to Backlog on the MediaWiki-Platform-Team board.

I'll deprioritize this because it doesn't seem to affect many people and probably only happens in an edge case (switching between multiple accounts). Also I don't have much idea what could be done here, short of someone being able to reproduce and inspect in detail what's happening with the cookies. None of us could reproduce it, and looking through the relevant code didn't surface anything suspect (as far as I can see from the code this behavior should be impossible without manual cookie tampering, which means I'm probably missing something, but just knowing that isn't much help).

The one thing we should probably improve is higher severity when logging unusual authentication failure code paths, so people don't have to set up WikimediaDebug, but now that Novem did set it up, I can't think of any extra information to log that would help further with this task, short of logging cookie values, which I rather wouldn't for a low-impact bug.

Change #1110362 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] CentralAuthSessionProvider: Improve logging

https://gerrit.wikimedia.org/r/1110362

Change #1110362 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] CentralAuthSessionProvider: Improve logging

https://gerrit.wikimedia.org/r/1110362