Page MenuHomePhabricator

(Some?) extension special accounts are unknown to CentralAuth
Closed, DuplicatePublic

Description

Example 1: MassMessage was recently fixed for dty.wikipedia (cf. T188014) however there's no CentralAuth data for MediaWiki message delivery for dty.wikipedia. MassMessage was recently used as well to send a message to wikimania2018.wikimedia.org. While the sending worked, there's no CentralAuth data for wikimania2018 either.

Example 2: Translate extension was recently installed on bd.wikmedia (cf. T188853). While the system account FuzzyBot do exist; there's no data, not even unnatached accounts for FuzzyBot@bdwikimedia

This is an issue as those accounts are becoming 'ghosts' and, for example, since they don't appear on CentralAuth, features such as GlobalUserPage won't work on them until they appear there.

Citing dtywiki, wikimania2018 and bdwikimedia as the two recent examples found out there. I don't know if there are more.

Event Timeline

I've found this was resolved in the past in T141465: FuzzyBot not attached on some Wikimedia wikis manually. Pings to @Anomie @Nikerabbit and @Legoktm here so they could do the same in this case for MediaWiki message delivery and FuzzyBot but instead using https://phabricator.wikimedia.org/diffusion/ECAU/browse/master/maintenance/attachAccount.php so we can attach all at once.

It looks like we don't have any hooks being run in the "system user created" code path. If we want CentralAuth to be aware of them, we'd have to add one. We might also want to check if anything is still using User::createNew() or User->addToDatabase() rather than User::newSystemUser(), or add the new hook to those functions instead of to User::newSystemUser() itself.

'LocalUserCreated' probably won't really work for this purpose, since the semantics there are that the user is being created during login or account creation rather than being created by a maintenance task of some sort.

Add a SystemUserCreated hook, maybe? I imagine most extensions that hook into LocalUserCreated don't want to act on system users (NewUserMessage for example).

It's not entirely clear in the case of CentralAuth, either: how do you avoid the situation where someone creates an account called MediaWiki message delivery on some small wiki and then waits for all the system users to get linked to that account? The promise given by newSystemUser is that it won't be possible to log into that account, and CentralAuth would have to preserve that somehow.

This should handle things:

  • If the user doesn't already exist centrally, you're good to create it.
  • If the user does exist centrally, but the global row has an invalid password and no email set, we're fine to attach it.
  • If the 'steal' flag is set, attach it after doing the following:
    • Invalidate the central password
    • Clear the central email
    • Invalidate the CA session
    • Submit jobs to the job queue to call User::newSystemUser( $name, [ 'create' => false ] + $options ) on every local wiki where the user is attached, to clear any local credentials and sessions.
  • Otherwise, don't attach, and ideally abort the local creation somehow too.

Can we, in the meanwhile, fix the CentralAuth issues with MediaWiki message delivery and FuzzyBot? Thanks.