Page MenuHomePhabricator

Repeatedly logged out on some local wikis
Closed, ResolvedPublicBUG REPORT

Assigned To
Authored By
AntiCompositeNumber
Mar 18 2025, 2:53 AM
Referenced Files
F58868498: image.png
Mar 19 2025, 4:45 PM
F58868489: image.png
Mar 19 2025, 4:45 PM
F58868477: image.png
Mar 19 2025, 4:45 PM
F58868455: image.png
Mar 19 2025, 4:45 PM
F58868408: image.png
Mar 19 2025, 4:45 PM
F58868393: image.png
Mar 19 2025, 4:45 PM

Description

NOTE: enwiki discussion thread: Trouble staying logged in?

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

  • Be me
  • Visit a Wikimedia site (but not any site, only some of them) and autologin via CentralAuth
  • Wait a bit (maybe about 10 minutes?) without loading a page on that site
  • Load/reload a page

I first noticed this on hewiki, but now it's happening on enwiki. I haven't noticed it on Commons.

What happens?:

You are centrally logged in as AntiCompositeNumber. Reload the page to apply your user settings.

Request ID: 0aaac960-379b-4860-a842-a6d6645fcc55

Request headers
GET /wiki/Main_Page HTTP/2
Host: en.wikipedia.org
User-Agent: ***
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://en.wikipedia.org/wiki/Special:Watchlist
Connection: keep-alive
Cookie: WMF-Last-Access=18-Mar-2025; WMF-Last-Access-Global=18-Mar-2025; enwikiUserName=AntiCompositeNumber; loginnotify_prevlogins=***; stopMobileRedirect=true; GeoIP=***; ss0-enwikiSession=***; ss0-centralauth_Session=***; enwikimwuser-sessionId=***; NetworkProbeLimit=0.001
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i
Response headers
HTTP/2 200 
date: Tue, 18 Mar 2025 02:25:54 GMT
server: mw-web.eqiad.main-ccbc59845-wnp2h
x-content-type-options: nosniff
content-language: en
accept-ch: 
vary: Accept-Encoding,Cookie,Authorization
expires: Thu, 01 Jan 1970 00:00:00 GMT
last-modified: Tue, 18 Mar 2025 02:09:01 GMT
content-type: text/html; charset=UTF-8
content-encoding: gzip
age: 0
x-cache: cp1112 miss, cp1112 pass
x-cache-status: pass
server-timing: cache;desc="pass", host;desc="cp1112"
strict-transport-security: max-age=106384710; includeSubDomains; preload
report-to: { "group": "wm_nel", "max_age": 604800, "endpoints": [{ "url": "https://intake-logging.wikimedia.org/v1/events?stream=w3c.reportingapi.network_error&schema_uri=/w3c/reportingapi/network_error/1.0.0" }] }
nel: { "report_to": "wm_nel", "max_age": 604800, "failure_fraction": 0.05, "success_fraction": 0.0}
set-cookie: WMF-DP=19b;Path=/;HttpOnly;secure;Expires=Tue, 18 Mar 2025 00:00:00 GMT
x-client-ip: ***
cache-control: private, s-maxage=0, max-age=0, must-revalidate, no-transform
accept-ranges: bytes
X-Firefox-Spdy: h2

The SUL dance with login.wikimedia.org and the various domains appears to work as intended. SUL3 does not appear to be involved, at least on the client side (CentralAuth requests have usesul3=0 and there are no requests to auth.wikimedia.org).

What should have happened instead?:

I should stay logged-in more than a few minutes.

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

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

Event Timeline

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

In my case, it's happening on iOS/iPadOS 18.3.2 on Safari via iPad 9th-gen. Not so much on iOS 16.7.10 on Safari via iPhone 8.

Yet to try out Chrome and Firefox.

What's your case?

Request ID: 0aaac960-379b-4860-a842-a6d6645fcc55

I don't see any logs with that ID. (Not necessarily wrong, not all requests generate logs; but that would mean nothing important happened during that request, authentication-wise.)

Cookie: WMF-Last-Access=18-Mar-2025; WMF-Last-Access-Global=18-Mar-2025; enwikiUserName=AntiCompositeNumber; loginnotify_prevlogins=*; stopMobileRedirect=true; GeoIP=*; ss0-enwikiSession=*; ss0-centralauth_Session=*; enwikimwuser-sessionId=***; NetworkProbeLimit=0.001

That is an anonymous request; your browser has no session cookies for enwiki at this point.
That doesn't prove much; SessionManager prefers session loss over anomalies and actively deletes cookies whenever it thinks they don't make sense or are inconsistent with backend state.

Wait a bit (maybe about 10 minutes?) without loading a page on that site

That would imply that 1) you either didn't check the "keep me logged in" checkbox, or some bug makes MediaWiki think you didn't, and 2) something is wrong with your CentralAuth session.
Normally the way it's supposed to work is:

  • If you check "keep me logged in", you get a a parent-domain token cookie (centralauth_Token) with one year expiry that match against the DB, and the persence of that cookie (plus a username cookie, IIRC) is enough to consider the request as logged-in and create a new session if necessary.
  • If you did not check it, you get a local session cookie (enwikiSession) and a parent-domain session cookie (centralauth_Session). The cookies have one-month expiry, but they just point to session store data which has shorter expiry (I think 10 minutes of inactivity for the local session, 24 hours for the central session).

So the "keep me logged in" option should keep you logged in basically forever, and absent that the parent-domain session cookie should keep you logged in for a day; and absent that, getting logged out after 10 minutes would be expected.

So I think the first thing to check is whether you see a the token cookie on enwiki and whether you see a token cookie on loginwiki.

On enwiki, without having logged in/out, page loaded logged-in:

image.png (369×1 px, 151 KB)

and on loginwiki:
image.png (349×1 px, 146 KB)

The centralauth_Token matches between enwiki and loginwiki. I first noticed this 14 March on hewiki without having recently logged in or out. I tried logging out and back in then (with keep me logged in, as always) to see if that changed anything and it did not.

Waited 10 minutes, refreshed the page, and now:

image.png (392×1 px, 158 KB)

centralauth_Token is the same.
Then I loaded a page on Wikitech, without reloading the enwiki page, and the cookies changed on enwiki:
image.png (287×1 px, 114 KB)

I reloaded the enwiki page again and got even fewer cookies (but still got the centralauth notification):
image.png (137×1 px, 51 KB)

I reloaded again and am logged in, and centralauth_Token is the same:
image.png (391×1 px, 163 KB)

The centralauth_Token matches between enwiki and loginwiki. I first noticed this 14 March on hewiki without having recently logged in or out. I tried logging out and back in then (with keep me logged in, as always) to see if that changed anything and it did not.

You mean it doesn't change enwiki and loginwiki having the same token, but the token itself does change when you log out and back in, right? If it didn't (and still worked) that would be quite bad.

Other than that this sounds like expected behavior. You have the right set of cookies, and the centralauth_* cookies should be the same on all domains.

Then I loaded a page on Wikitech, without reloading the enwiki page, and the cookies changed on enwiki

Let's see if the patch for T389318: Unable to login via SUL3 on wikitech.wikimedia.org ("Session hijacking" error) fixes that, although I'm not sure how a Wikitech cookie misconfiguration would cause this. If that doesn't work, can you check exactly which cookies change and how? (Does wikitech make an autologin or other cross-domain request? It's a *.wikimedia.org, it can't directly affect enwiki cookies.)

FWIW at least on Chrome the developer tool is a bit unreliable and sometimes you just don't see cookies for other domains, with no warning.

You mean it doesn't change enwiki and loginwiki having the same token, but the token itself does change when you log out and back in, right? If it didn't (and still worked) that would be quite bad.

The first one, yeah.

The wikitech thing may or may not be a red herring, since I get logged out locally whether I load any other pages at all. I noticed it and it made the Firefox dev tools window for the enwiki page highlight so I figured it was worth mentioning.

The Wikitech issue is fixed now. In any case, if reloading the page on one domain changes cookies on another domain, and the two domains don't share a parent, there has to be a cross-domain request where the cookie change actually happens. If you could track that down, that would help a lot.

The Wikitech issue is fixed now.

Correction, the Wikitech issue is fixed now.
(ref. T389433: Fix stuck old cookies on Wikitech)

Reedy renamed this task from Repeatedly logged out on some local wikis to Repeatedly logged out on some local wikis.Mar 20 2025, 9:50 PM

So we have seven reports sofar (including on the enwiki VP), people say it started happening on the 18th or 19th.
SUL3 login was only enabled for group 0 at the time, and the train was on group 0 on the 18th and group 1 on the 19th, so this is probably caused by some backport. The changes on those days that seem potentially relevant:
rECAU5e369d036b8e: Do not initiate central login on the passive central domain (17th, around 22:00 UTC)
rECAU8c9fb0fd4f72: Do not schedule edge login recursively (18th, 1:00)
Both of them are very minimal changes, but the first unbroke rECAUb10a647882cd: Add passive central domain to edge login list (which was merged some weeks ago but didn't really work until the first backport fixed it, and then started causing trouble until the second backport fixed it properly), so maybe the passive domain edge logins are somehow causing people to be logged out? Sounds implausible, but I don't have a better hypothesis.

I first noticed this on hewiki only early on the 14th. I remember seeing a connection to auth.wm.o in the devtools, but didn't look further because I was having multiple issues while making a series of complex oversight actions. Then it started on enwiki on the 17th/18th. I haven't had the issue in the last 48 hours.

14th was as a Friday (so no changes); that was the week of the rolling out SUL3 signups to group2, which shouldn't have affected existing users. Backports / train changes around that time:
rECAU9023f5d25de8: SUL3: Attach SUL mode to the return URL of local wiki (10th, around 16h)
rECAU4ffb2574f068: SpecialCentralAutoLogin: Handle nullable wiki ID (same)
rECAUfa81f3837ec4: Simplify return URL parameter handling (12th/13th, with the train)
None of them seem even remotely related.

In general, an auth.wikimedia.org request cannot directly affect your *.wikipedia.org cookies. But autologin involves a lot of bouncing between the two domains, so I think the least unlikely hypthesis is something going wrong with that. Maybe T375796#10665553? That does involve (erroneously) issuing a new set of cookies on the wiki you are on, but as far as I can see the cookies should be valid.

Anyway, do others still experience this issue? Logout issues are notoriously hard to debug, so if it's gone, I'd leave it at that.

Tgr claimed this task.

Assuming this isn't happening anymore, please feel free to reopen if you are still encountering it.

I logged out of the iOS app to test something yesterday, and am now not remaining logged in on my laptop.

As in, you are getting logged out repeatedly? Logout on one device terminating your sessions on all other devices as well is expected (T37220: Allow per-session log out).

I got centrally logged out, I logged back in on enwiki, and am now being inconsistently locally logged out on local wikis (the central session remained logged-in after logging in the first time). JS autologin sometimes works, but sometimes it doesn't and I have to click login again.

Then Firefox crashed and restarted and now things seem to be working correctly.

Firefox crashed again (I have too many tabs) and now enwiki is doing it again.