Page MenuHomePhabricator

Check global rights during autocreation
Open, Needs TriagePublic

Description

We want to do various permission checks during autocreation (e.g. maybe the user's IP is blocked but they have the ipblock-exempt right as global sysops?), but there doesn't exist any good mechanism in MediaWiki to do this, since the local account doesn't exist yet.

Some options:

  • Just support anonymous User objects with a name set (e.g. CentralAuth checks $user->isRegistered() before giving it any rights, it would instead check $user->isRegistered() || $user->isItemLoaded( 'name' )). Simple but scary.
  • Create a new hook, or maybe a service similar to CentralIdLookup, which takes a username and tells if that username has any global rights. It would be the caller's responsibility to ensure that the user is authenticated with the given central ID. The autocreation logic would probably be the only caller ever so this feels like overkill.

Event Timeline

I stumbled on this semi-surprising behavior today. My https://meta.wikimedia.org/wiki/Special:CentralAuth/BDavis_(WMF) staff account has the global-ipblock-exempt permission, but I was unable to attach by login at https://as.wikiquote.org. I received this error notice instead of the expected successful login:

Auto-creation of a local account failed:

Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪Metawiki>Bsadowski1‬. The reason given is Open proxy/Webhost: See the help page if you are affected: Abused web host / VPS: .

Start of block: ১০:০৫, ২৭ ফেব্ৰুৱাৰী ২০২৩
Expiry of block: ১০:০৫, ২৭ ফেব্ৰুৱাৰী ২০২৫

Your current IP address is 2001:470:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX. The blocked range is 2001:470:0:0:0:0:0:0/32.

Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

Per T330602: Special:CreateLocalAccount should comply with user's block-bypass permissions Special:CreateLocalAccount now does take ipblock exemptions into account, so you can ask a steward or meta admin to create your account.

Just support anonymous User objects with a name set ... Simple but scary.

I guess it's not that scary. What are the situations in which you have a named anonymous account?

  • Before autocreation. Adding rights would fix this bug, doesn't otherwise seem problematic (the worst thing that can happen is that the account does / doesn't get autocreated when it shouldn't / should).
  • During revision import (although I'm not sure the current implementation uses User objects at all). Permissions of the revision author don't matter.
  • For global blocks. Again, the permissions of the block author don't really matter.

The potentially scary scenario would be the one where someone registers an unattached local account which unherits permissions from a different user's central account, maybe via a race condition in registration; but the extension should already handle such race conditions (the old and new names are blocked from creation for the entire duration of the rename). So I think we can go with the simple solution here.

The same situation can also arise during normal account creation, once T354928: Allow logging and possibility to enact mitigations for actions for IPs with negative IP reputation data is in place. And we could probably simplify CheckBlocksSecondaryAuthenticationProvider too.

Tgr removed Tgr as the assignee of this task.Jan 12 2024, 7:42 PM
Tgr moved this task from Current Sprint to Soon on the MediaWiki-Platform-Team board.

Never mind, I got confused, this is not actually relevant to T354928. We should probably still fix it soon, but it isn't a blocker for ongoing work.

Change #1017883 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/extensions/CentralAuth@master] look up global user rights for anon users with name set

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

The above patch fails CI for three tests not in the Database group. All three call User::isAllowed() at some point, which now would require database access. Two tests are in ConfirmEdit and one is in core (DumpableObjectsTest). I could add al lthree to @group Database or I could mock out CentralAuthHooks and have the onUserGetRights method always return true in those tests, or maybe there's some better approach. Poking @Tgr for advice or a pointer.

The problem is that User::isRegistered() tries to load the user, and User::isItemLoaded( 'name' ) is always true if we tried to load the user, even if it's an anonymous user.

The simplest solution would be to use $user->mFrom === 'name' instead of $user->isItemLoaded( 'name' ) but that's one of those grandfathered-in public properties that we probably don't really want to be public. Or we could check whether the username is an IP address but that feels convoluted.

Maybe there should be something like a User::hasUsername() method which is true iff the user has a non-zero ID (after loading) or has been created from a username.

Change #1019731 had a related patch set uploaded (by ArielGlenn; author: ArielGlenn):

[mediawiki/core@master] add a tiny helper function to check if a User has a name set

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

Change #993242 had a related patch set uploaded (by XtexChooser; author: XtexChooser):

[mediawiki/core@master] AuthManager: perform auto-creation as target user

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

Change #993242 merged by jenkins-bot:

[mediawiki/core@master] AuthManager: perform auto-creation as target user

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

Change #1019731 merged by jenkins-bot:

[mediawiki/core@master] add a tiny helper function to check if a User has a name set

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

Change #1017883 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] look up global user rights also for anon users with name set

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

Should go live with the train next week. Recommended Tech News notice:

When visiting a wiki where you don't have a local account yet, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules.

Hey @bd808 are you in the position to check whether autocreate is now working for you from a blocked IP range, or did you work around this issue via stewards or whatnot?

Not for me on en wikivoyage and wikiversity. But seems working on most small wikis.

Not for me on en wikivoyage and wikiversity. But seems working on most small wikis.

For those following along, see https://meta.wikimedia.org/wiki/Special:CentralAuth?target=XtexChooser for autocreate working on a number of wikis. Odd that it would selectively fail on en.wikivoyage/wikiversity though.
@XtexChooser What error message did you get? Did it resemble the one in T316303#9299843 or was there something at all different?

It was saying I am globally IP blocked. idk why but now everything is fine and I am able to autocreate accounts. I created a couple of local accounts and it worked fine. Thanks!

It was saying I am globally IP blocked. idk why but now everything is fine and I am able to autocreate accounts. I created a couple of local accounts and it worked fine. Thanks!

Glad to hear! Closing this in that case, thanks for checking!

Hey @bd808 are you in the position to check whether autocreate is now working for you from a blocked IP range, or did you work around this issue via stewards or whatnot?

Attempting to login to https://kus.wikipedia.org/ using my BDavis (WMF) SUL account which is a member of the Global IP block exemptions group is actively returning an auto-creation failure in the same manner as T316303#9299843.

Auto-creation of a local account failed:

Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis.

The block was made by ‪Metawiki>Bsadowski1‬. The reason given is Open proxy/Webhost: See the help page if you are affected: Abused web host / VPS: .

Start of block: 04:35, 27 Fulumfug/Nwadisatan' 2023
Expiry of block: 04:35, 27 Fulumfug/Nwadisatan' 2025

Your current IP address is 2001:470:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX. The blocked range is 2001:470:0:0:0:0:0:0/32.

I tried this from the command line and it seemed to work fine:

tgr@mwmaint1002:~$ mwscript shell.php bewwiki
> $u = MW::user('BDavis (WMF)')
= MediaWiki\User\User {#5986
    +mId: 0,
  ...
> RequestContext::getMain()->getRequest()->setIP(\Wikimedia\IPUtils::canonicalize('2001:470:1:1:1:1:1:1'))
= null
> (string)MW::srv()->getAuthManager()->autoCreateUser($u, MediaWiki\Auth\AuthManager::AUTOCREATE_SOURCE_SESSION, false, true, $u)
= "<OK, no errors detected, no value set>"

so maybe it's some other permission check during login that fails?

rMW50dd99eefb38: AuthManager: perform auto-creation as target user should probably have updated the autocreation call in Setup.php, not the one in AuthManager. Passing a named user object through the entire login process seems hard, and in any case, there is no reason to force the user to manually log in.

There are still scenarios where autocreation would occur during login but not during setup, but those are much more rare.

(btw I did autocreate BDavis_(WMF)@kuswiki in the process of testing. You are very close to running out of wikis to test on.)

oops thanks for bd808's test, I found that I also could not auto-create on kus WP, getting the same global IP blocked error.
Maybe this task should remain open and unresolved?

Reopening per T316303#9838643 and T316303#9862530. Not sure if this should really be forked into a new bug report however, so if that seems more correct to folks please do so.

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

[mediawiki/core@master] AuthManager: Perform auto-creation as target user in Setup.php also

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