Per T15611: Blocking account creation on an IP address should apply to logged in users too it is intentional that blocks that disable createaccount should have that applied to logged in users; however, I don't see ipblock-exempt mentioned. r41150 was by @aaron with follow-up by @tstarling.

	/**
	 * Get whether the user is explicitly blocked from account creation.
	 * @return bool|AbstractBlock
	 */
	public function isBlockedFromCreateAccount() {
		$this->getBlockedStatus();
		if ( $this->mBlock && $this->mBlock->appliesToRight( 'createaccount' ) ) {
			return $this->mBlock;
		}
		# T15611: if the IP address the user is trying to create an account from is
		# blocked with createaccount disabled, prevent new account creation there even
		# when the user is logged in
		if ( $this->mBlockedFromCreateAccount === false && !$this->isAllowed( 'ipblock-exempt' ) ) {
			$this->mBlockedFromCreateAccount = DatabaseBlock::newFromTarget(
				null, $this->getRequest()->getIP()
			);
		}
		return $this->mBlockedFromCreateAccount instanceof AbstractBlock
			&& $this->mBlockedFromCreateAccount->appliesToRight( 'createaccount' )
			? $this->mBlockedFromCreateAccount
			: false;
	}

(That's all the further that I'm able to get investigating this.)

I have just encounted this issue when trying to create an account for a trainee at the university where I am Wikimedian in Residence, via en.Wikipedia. I have "IP Block exempt" and "account creator" rights on that project.

It should be noted that DatabaseBlock::newFromTarget (used here) chooses the most specific IP block. Blocking an IP range from creating accounts might not have the desired affect if there are more specific IP blocks which allow account creation. This is only in the case of wanting to block admins from creating accounts, which we may not want to do in the first place (as mentioned above).

Also, for testing purposes, I believe the corresponding API call that checks whether a particular $username can be created is: w/api.php?action=query&list=users&usprop=cancreate&ususers=$username. This also exhibits the same bug/behaviour as in the description.

Wondering if there's any progress on this? I see that blocking logged-in users from creating accounts on account-creation-blocked IPs is intentional per T15611, and I agree, but surely that was not also meant to block ipblock-exempt users? ipblock-exempt should exempt users from ALL IP block settings - if we didn't want to grant users full exemption from IP blocks we would not give them the permission.

Change 555282 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] Fix AuthManager::canCreateAccount method

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

Cannot reproduce. However, normal users (no IPBE) cannot create accounts, even with softblocks.

Aha...with sysop, the form shows, but doesn't allow me to create the account anyway - even with my steward account.

I've digged into this a little. AuthManager::canCreateAccount calls CheckBlocksSecondaryAuthenticationProvider with the "to be created" user, which doesn't have IPBE. I think CheckBlocksSecondaryAuthenticationProvider shouldn't be called at all, given the special page itself checks for permissions :-).

Given this is a core issue, calling CPT to help to decide about the best fix.

TL;DR: Removing CheckBlocksSecondaryAuthenticationProvider::testUserForCreation() and at the same time adding a call to $user->isBlockedFromCreateAccount() into AuthManager::autoCreateUser() seems like the thing to do here.

In T189362#6009701, @Urbanecm wrote:

I've digged into this a little. AuthManager::canCreateAccount calls CheckBlocksSecondaryAuthenticationProvider with the "to be created" user, which doesn't have IPBE. I think CheckBlocksSecondaryAuthenticationProvider shouldn't be called at all,

As stated, that doesn't really make sense. What I think you mean is something along the lines of "CheckBlocksSecondaryAuthenticationProvider::testUserForCreation() shouldn't call $user->isBlockedFromCreateAccount()", which would reduce it to the no-op implementation in its parent class.

It does seem that always checking ->isBlockedFromCreateAccount() on the to-be-created user was a bug. Looking back at rMWd245bd25aef1: Add AuthManager, originally that was only done on auto-creation (where it does make sense, and we need to make sure that continues to happen). Then PS90 accidentally made it apply always, and PS101 further obscured the issue. While we could go back to having CheckBlocksSecondaryAuthenticationProvider only do the test on autocreation, probably when PS101 introduced checkAccountCreatePermissions() it should have just added the IP-block check directly to AuthManager::autoCreateUser() too to match.

given the special page itself checks for permissions :-).

AuthManager::checkAccountCreatePermissions() is what checks the relevant permission. Which is good, because just the special page checking wouldn't work for account creations via the Action API.

The special page may check too, in order to provide a better error message than AuthManager generates for common cases.

Change 654273 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@master] CheckBlocksSecondaryAuthenticationProvider: Check creator's permissions, not created user's permissions

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

Change 555282 abandoned by Ammarpad:
[mediawiki/core@master] Do account-creation block check (for the new user) in AuthManager::autoCreateUser()

Reason:
couldn't remember what this was for

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

Change 555282 restored by Ammarpad:
[mediawiki/core@master] Do account-creation block check (for the new user) in AuthManager::autoCreateUser()

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

A patch for this can be tested on Patch Demo https://patchdemo.wmflabs.org/wikis/555282 or make a new wiki with the change id: 555282

1. Know your IP
2. Log in with default Patch Demo account
3. While logged-in as Patch Demo, block the IP with account creation disabled.
4. Then go to Special:CreateAccount and create new account <-- this should succeed
5. Log out (Patch Demo) and then now log in with the new account created in step 4.
6. Go to Special:CreateAccount and attempt creating new account <-- this should fail
7. Log out from the second account and attempt account creation as the IP <-- this should fail too

Change 555282 abandoned by Ammarpad:
[mediawiki/core@master] Do account-creation block check (for the new user) in AuthManager::autoCreateUser()

Reason:

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

Worth noting with the rise of iCloud Private Relay, this may be more impactful to groups (sysops, IPBE) who normally wouldn't see an impact from this. Hoping this gets resolved soon.

I've just bumped in to this as an ENWP account creator. At work, no Wifi, using mobile data... can't create accounts even though the range block is anon only.

Me as enwiki account creator(acc team) and an ipblock got me. I can't change my network as that's the only network available at my location so, it's not just accounts creation, but it has stopped me from using urlshortener. And I don't know what else. No user rights are going to help me in this situation. Hopefully this ticket gets resolved soon. I am not comfortable using the acc tool for account creation but rather I prefer using it manually at special:createaccount. Thanks in advance

In T189362#8162288, @Sureshkhole wrote:

Me as enwiki account creator(acc team) and an ipblock got me. I can't change my network as that's the only network available at my location so, it's not just accounts creation, but it has stopped me from using urlshortener. And I don't know what else. No user rights are going to help me in this situation. Hopefully this ticket gets resolved soon. I am not comfortable using the acc tool for account creation but rather I prefer using it manually at special:createaccount. Thanks in advance

As far as I know, url shortener could be related to (ip) blocks affecting you on meta, which might be a different one.

Can anyone test? I tested this today on test-wiki and was able to create accounts from a blocked IP when IPBE was applied.

I didn't see any patches above, is this expected to be working now?

I can confirm it changed, but I don't know if it was intentional.

There was some change in rMW1f9c3a45668d: Move AuthManager::checkAccountCreatePermissions to Authority. by @Pchelolo.

In T189362#8356363, @Oshwah wrote:

Can anyone test? I tested this today on test-wiki and was able to create accounts from a blocked IP when IPBE was applied.

I tested on zhwiki and it also works fine now.

Means? The change which was on waiting for ages got resolved automatically?

The linked patch above mentions @Pchelolo (a former WMF staffer) - so follow up there is probably a dead end

Change 654273 abandoned by Urbanecm:

[mediawiki/core@master] CheckBlocksSecondaryAuthenticationProvider: Check creator's permissions, not created user's permissions

Reason:

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