Page MenuHomePhabricator

Investigate why CentralAuth edge login fails in browsers that do not block third-party cookies
Closed, ResolvedPublic

Description

T345249: Mitigate phase-out of third-party cookies in CentralAuth explains why CentralAuth cross-project login is broken in browsers that block third-party cookies. It does not explain why it's partially broken in browsers that don't block them (notably, Chrome with default settings). We have mostly assumed that it's for the same reason, but now that we have mapped the exact level of browser support and know that it isn't, we should investigate it.

By "partially broken" I mean that when you visit a new project, central autologin works (your first pageview is logged out, but you get a notification of being logged in in the background, and your next pageview is logged in) but edge login does not (you should get logged in to all projects at the same time in the background when you log in, so when you visit another project you already have a session). The fact that the mechanism for the two is almost the same (central autologin makes a call to Special:CentralAutoLogin in a <script> tag, edge login makes a call to Special:CentralAutoLogin in an <img> tag) suggests that this might be something broken on our side rather than a browser limitation.

Event Timeline

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

When using a fresh Chrome browser profile to log in on meta.wikimedia.org and then filter the network log to en.wikipedia.org requests + requests redirected from there, this is what I get:

  • https://en.wikipedia.org/wiki/Special:CentralAutoLogin/start?type=1x1&from=metawiki 302
  • https://login.wikimedia.org/wiki/Special:CentralAutoLogin/checkLoggedIn?wikiid=enwiki&proto=https&type=1x1&from=metawiki 302, auth cookies seem in order
  • https://en.wikipedia.org/wiki/Special:CentralAutoLogin/createSession?token=...&type=1x1&from=metawiki&proto=https 302, Set-Cookie: enwikiSession + ss0-enwikiSession
    • ss0-enwikiSession fails, as expected (it's for compat with old browsers)
  • https://login.wikimedia.org/wiki/Special:CentralAutoLogin/validateSession?token=...&wikiid=enwiki&type=1x1&from=metawiki&proto=https, 302, auth cookies seem in order
  • https://en.wikipedia.org/wiki/Special:CentralAutoLogin/setCookies?type=1x1&from=metawiki&proto=https 200 (with invisible pixel), X-Centralauth-Status: success, but no Set-Cookie header

so it seems like setCookies runs successfully (calls doFinalOutput( true, 'success' )), but doesn't actually set any cookies. There is no way to reach one of those calls without passing through the code block that sets the authenticated session, so somehow that block must be ineffective.

There are two different enwiki setCookies responses in logstash, from the same host, with ~50ms difference:

https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2023.10.08?id=B_Y2DYsB2F9ZGV9iEloZ

@timestamp: Oct 8, 2023 @ 02:55:27.919
channel: session
host: mw2387
http_method: GET
level: INFO
message: Persisting session for unknown reason
referrer: https://meta.wikimedia.org/
reqId: 815dc804-7c97-4da7-ab1a-fc5bff8b81c0
server: en.wikipedia.org
timestamp: 2023-10-08T02:55:27+00:00
type: mediawiki
url: /wiki/Special:CentralAutoLogin/setCookies?from=metawiki&proto=https&type=1x1
user: TgrTest
wiki: enwiki

https://logstash.wikimedia.org/app/discover#/doc/logstash-*/logstash-mediawiki-1-7.0.0-1-2023.10.08?id=Hv82DYsBC5yW6bzkERlv

@timestamp: Oct 8, 2023 @ 02:55:28.062
channel: session
host: mw2387
http_method: GET
level: INFO
message: Persisting session due to no pre-existing stored session
referrer: -
reqId: 1db798ee-34ba-4133-a9fb-ecb83793f354
server: en.wikipedia.org
timestamp: 2023-10-08T02:55:28+00:00
type: mediawiki
url: /wiki/Special:CentralAutoLogin/setCookies?from=metawiki&proto=https&type=1x1
user: <anon>
wiki: enwiki

(Or maybe it's the same response, but the request ID and referred have been reset due to some bug in the logging framework? Doesn't seem likely.)
Only one of those responses shows in my browser's network tab. The one with the referrer set, presumably? No idea what's going on.

Searching for all logs with those reqIds doesn't turn up anything interesting: https://logstash.wikimedia.org/goto/a1cc983b0b3c4b3db0b2c787d5c85b0c (yes we need better logging)

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

[mediawiki/extensions/CentralAuth@master] Fix Special:CentralAutoLogin/setCookies

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

Change 964175 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Fix Special:CentralAutoLogin/setCookies

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

Suggested user notice:

SUL edge login should have been fixed for some browsers (Chrome, Edge, Opera): if you visit a new sister project, you should be logged in automatically without the need to click Login or reload the page. Feedback on whether it's working for you is welcome. (1)

(I have no idea what's up with the duplicated setCookies Logstash entry. Doesn't seem related to the issue fixed by the patch, as far as I can see.)

Tested on Chrome on mediawiki.org (the only group0 edge login wiki), seems to work.

Tested in Chrome on various group2 wikis, works. There are some open questions not strictly related to the task:

  • The issue was caused by trying to set cookies when the response body was already started, why didn't that result in an error being logged?
  • What's up with the weird double request in T347889#9233353?
  • Did we really cause this way back in 2015 during the AuthManager transition and not noticed it for several years?
In T347889#9246527, @Tgr wrote:
  • The issue was caused by trying to set cookies when the response body was already started, why didn't that result in an error being logged?

Filed that as T348801: No warning logged in Wikimedia production when CentralAuth tries to send headers after body. The others don't seem that important.

Quiddity subscribed.

@Tgr Thanks for the draft! Added (with slight tweaks) to https://meta.wikimedia.org/wiki/Tech/News/2023/42 -- Please edit that directly (and within ~24 hours), if needed.