Page MenuHomePhabricator

ConfirmAccount enabled but doesn't block createaccount on instance
Closed, ResolvedPublic2 Estimated Story Points


My instance (id: 39) appears to have the option "Accounts must be requested" enabled, as it shows as toggled on in the appropriate section of the dashboard.

The option is described as "Disable direct account creation and require the approval of new accounts by a site bureaucrat.

This is powered by the ConfirmAccount extension."

Screenshot_20221108-172208_Chrome_Beta.png (933×875 px, 75 KB)

Nonetheless new spam users have been registering and creating user pages (although I have just nuked 300+ of them). The issue appears to have persisted since at least August 29, when the first recent new account was created. I have not turned it on or off today in case there is some state on your end that would be erased by this.

I think at one point a few months ago I turned it off in case someone wanted to register for a short time, but I also think I turned it on again soon after. Either it is on and isn't working, or incorrectly shows as on even though it is actually off. (Having a separate "Set option" button for a toggle is just a bad idea IMO - it should show the current state and change it immediately.)


  • Only bureaucrats can create accounts when the confirmaccount setting is enabled

Event Timeline

It seems Special:CreateAccount is still enabled even though the link at the top right is to Special:RequestAccount. Obviously, bots don't click the link, they just go to the relevant page (or use the createaccount API).

I notice on MediaWikiWiki:Extension:ConfirmAccount the following warning:

For MediaWiki 1.35+ there appears to be an issue with permissions when using wfLoadExtension(): the createaccount permission may not be revoked from the all users group. Use $wgGroupPermissions['*']['createaccount'] = false; to prevent account creation until this is resolved.

    If you want the bureaucrats to be able to accept new requests, you need to set the permission explicitly: $wgGroupPermissions['bureaucrat']['createaccount'] = true; to enable them.)

Indeed, (all) still has the createaccount right and while the InviteSignup LocalSettings block sets the group permission to false, the equivalent block for ConfirmAccount does not revoke createaccount for *, nor permit it explicitly for bureaucrats.

GreenReaper renamed this task from ConfirmAccount appears enabled but not working on instance to ConfirmAccount enabled but doesn't block createaccount on instance.Nov 16 2022, 6:27 PM

Not directly linked but potentially also an issue to bear in mind: per T168783, the captcha used on Special:RequestAccount may not be verified until 1.40+ (unless you use the updated version in master, which the extension page suggests is not compatible).

For cleanup, I copied the User: namespace page list and dumped it into Special:DeleteBatch to clear out the ones that existed already, since they were past the recent changes limit for Special:Nuke.

Evelien_WMDE set the point value for this task to 2.

I have the same problem here: , where yesterday and today new spammer users have been created, despite "accounts must be requested" option in wikibase cloud dashboard being set to "on". In Spring 2022 there was another time frame when spammers got in (that seems to have ended in April). The dashboard option was set to "on" all the time.

Tarrow removed Tarrow as the assignee of this task.Jan 2 2023, 9:20 AM
Tarrow subscribed.

This issue appears to have been resolved in that the account creation has been prohibited and no new accounts have been created since the afternoon of December 12.

There is now the separate issue that a lot of requests are getting through spam filters and clogging up the list:
44 open email confirmed account requests are pending. Your attention is needed!
prospective authors (open requests [185]
But the issue mentioned here appears resolved.

Evelien_WMDE subscribed.

FYI: I created a followup ticket to figure out what to tweak to reduce the spam that's taking place:
Needs further discussion to figure it out, but it's on our radar as a followup of this ticket. This ticket can now be closed.

GreenReaper claimed this task.