T363695: Create a Wikimedia login domain that can be served by any wiki automatically runs all login/signup code in the context of the originating wiki.

T363695: Create a Wikimedia login domain that can be served by any wiki automatically runs all login/signup code in the context of the originating wiki.

Per T363695#10309189, we won't use loginwiki.

List of affected accounts: F57698265

Wrt cleanup, what we need to do here is to find all the non-Wikitech accounts where

1. the account is not attached to a central account
2. but the central account exists
3. and there is an identically-named Wikitech account

and attach those to the global account.

Someone who has been affected by this, such as @eugrus or @Robertsky, would you be able to double-check the fix by going to a wiki where you don't have a local account (you can find one via Special:CentralAuth) and logging in if needed?

In T378289#10288451, @Tgr wrote:

There have been 195 Not centralizing auto-created user {username}, central account doesn't exist and 133 Not centralizing auto-created user {username}, unattached accounts exist errors since we enabled logging.

In T379589#10313048, @Krinkle wrote:

Tagging RL since this likely needs a patch to maintenance/purgeMessageBlobStore.php which is part of ResourceLoader.

Chrome developer console says

Cookies with the SameSite=None; Secure and not Partitioned attributes that operate in cross-site contexts are third-party cookies. Chrome is moving towards a new experience that allows users to choose to browse without third-party cookies.

Reviewed the i18n messages marked as raw HTML in T377222: Don’t use raw HTML messages in safe mode. None of those should be reachable on the shared login domain, plus they are marked as raw HTML so not really vulnerable, but we should get rid them anyway. I'll push some patches.

Tested with the following URLs (after setting $wgUseXssLanguage = true; $wgLanguageCode = 'x-xss';):

Special:Userlogin
Special:Userlogout
Special:CreateAccount
Special:PasswordReset
Special:Captcha
Special:ChangeCredentials
Special:DisableOATHForUser
Special:OATHManage
Special:VerifyOATHForUser
a permission error
a rest.php exception
an api.php error
an api.php module disabled error

with the common authentication extensions (CentralAuth, OATHAuth, ConfirmEdit etc) installed, and did some basic interactions where appropriate (e.g. failing login often enough to get a captcha, passing the login screen to get a 2FA check, setting and unsetting 2FA).

We did not backport due to scap issues (T379589). It will happen today.

git log -S says the use of WMF_MAINTENANCE_OFFLINE is new (first used in the "Containerize MediaWiki script execution" patch that got reverted and unreverted multiple times).

See also T379589: scap backport fails at purgeMessageBlobStore.php with getaddrinfo failed which seems to have the same cause (using a mock DB config for offline operations) but occurred at a later scap step. And another scap attempt worked fine yesterday.

Name or service not known (WMF_MAINTENANCE_OFFLINE_placeholder)

In T378663#10311223, @Krinkle wrote:

This requires temporarily making yourself a local steward, eg via eval.php or createAndPromote.

rMW6965c29e74c0: PageUpdater: restore call to RevisionFromEditComplete has been deployed to production, please re-test.
(Scap failed with T379589: scap backport fails at purgeMessageBlobStore.php with getaddrinfo failed but AIUI that shouldn't affect the success of the deployment.)

Might be a one-off, since it failed at purgeMessageBlobStore.php (per the stack trace, at the very beginning, before doing any actual purgind) and the patch I was backporting didn't involve any message changes, I did not rerun.

Could just pass in an UltimateAuthority. That would override most checks, which in the context of a maintenance script is probably a good thing.

In T378401#10307538, @ArielGlenn wrote:

One thing about those errors is that we'll see an error for the same one 23 times, due to the run frequency and time period covered by the script. If that's still ok, I can abandon the other patches.

Delete all the [[MediaWiki:Sitesupport-url]] pages.

In T377561#10308497, @kostajh wrote:

This seems worthwhile, if it means we have improved central session reliability.

That makes sense, although it would be nice to document which OutputPage methods do/don't need a title set. But yeah, requiring null checks in BeforePageDisplay seems unreasonable. Thanks for the patch.

FWIW this works as expected for me (in Chrome, which does not block autologin yet).

In T378401#10303452, @ArielGlenn wrote:

I am not sure how much value we are really adding here.

In T378401#10271287, @ArielGlenn wrote:

@Tgr --startdate "5 days ago" works as expected, you're all set already.

In T379254#10303960, @DAlangi_WMF wrote:

Seems like task T377561: "Keep me logged in" flag unreliable on the central domain is related to this task.

Let's backport the (hopefully) fix on Monday. After that, we can run attachAccount.php on the affected accounts.

This should probably be a support request to the maintainer of Cradle (not necessarily on Phabricator), not a task about the OAuth framework.

@MPThLee if you want to maintain the Sentry extension, feel free to unarchive it. (Or just fork it and host it elsewhere.) But it was unmaintained for a long time, and Sentry is not opensource anymore, so it's about to be removed (T379212: Archive the Sentry extension).

We did want a wikispore vanity domain. T365641 was about a different server though, which runs OWMF.

Turns out it was completely unrelated to Minerva. One CentralAuth test had the potential to break another one, if it got executed first. Not sure why CentralAuth tests are executed in a different order in CentralAuth's own CI than in Minerva's - maybe a side effect of the new parallel test execution?

I assume this was meant fort MW-Interfaces-Team.

In T378289#10292885, @Tgr wrote:

Not centralizing auto-created user {username}, central account doesn't exist errors are all from temp users, and all on temp-enabled wikis. (@kostajh FYI)

Probably just decline? Does not make sense to keep the task open if the reason to not do it is we don't agree it should be done.

Other similar things maybe worth tracking: MEDIAWIKI_JOB_RUNNER, RUN_MAINTENANCE_IF_MAIN, MEDIAWIKI_INSTALL.

In T363639#10266134, @Krinkle wrote:

@Tgr If I understand the above correctly, this is works well enough on PHP 7.4-8.1 in practice with webauthn-lib v3.

Not centralizing auto-created user {username}, central account doesn't exist errors are all from temp users, and all on temp-enabled wikis. (@kostajh FYI)

Caused by rEJSCde153cf3f4da: Initial shared usage tracking for cross-wiki JSON data references / T374747: Usage tracking table for JsonConfig data pages presumably. Seems like it's missing a $wgTrackGlobalJsonLinks = false.

Seems like something in Minerva or its tests makes OutputPage::getModules() return an empty array.

In T378780#10283290, @Daimona wrote:

It seems like that there have been a few changes to CentralAuth today

There have been 195 Not centralizing auto-created user {username}, central account doesn't exist and 133 Not centralizing auto-created user {username}, unattached accounts exist errors since we enabled logging.

In an ad-hoc test, the start/complete steps of central login take me 300ms each, and the refreshCookies step takes 200ms. No idea how representative these numbers are.

(moving back on workboard for request visibility)

This seems to me like minimal value for a lot of work, at least I don't see how it could be done without having to update every rights-related UI in existence.

Thanks for working on this!

Thanks for investigating that. Yeah we should just move the constant.

There are some smaller ongoing tasks that are relevant from a security perspective (T375788, T376488, T375796, T373737), I'll update the list of patches with those in the next few days as they get done; but apart from that, I think the request is ready. I'll make some diagrams about the old and new authentication flow soon. Please let me know what other information will be useful.