Page MenuHomePhabricator

Titleblacklist entries with <newaccountonly> should affect automatically created accounts with SUL
Closed, ResolvedPublic

Description

The username above contains a personal attack towards one of Russian Wikipedia sysops. Both attacking word and user's surname are forbidden in [[ru:MediaWiki:Usernameblacklist]], but such accounts can be still created with SUL. Global blacklisting is not helpful here, because (1) we are not always able to wait for a meta sysop and (2) global checks may prevent a fair registration in another project, because a word that is offensive in one language may be quite normal in other one.

Therefore account autocreation should be forbidden if the username is blacklisted locally. I can't currently think of what will be the best — just leave the user logged out, or create the account and automatically block it — but the current situation definitely has to be fixed.


Version: unspecified
Severity: major

Details

Reference
bz14629

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 21 2014, 10:09 PM
bzimport set Reference to bz14629.

I could swear I fixed this a few weeks ago.

I see the need. Now if if is fixed, we need a workaround.
Currently, a username blacklist can be overriden by a sysop creating the account. But there's no such option if it's a SUL account.
Perhaps allow create and autoblock it? Then sysops could disable the block.

cometstyles wrote:

Not fixed yet, we just had a a known troll create multiple "bad usernames" just yesterday, probably needs a fix.

Domain: "MediaWiki/Blocking" -> "MediaWiki extensions/UsernameBlacklist"

The cause of this issue is that CentralAuth circumvents hooks AddNewAccount and RemoveNewAccount because it user autocreate. The same issue was met for extension NewUserMessage. This was resolved in r38769. UsernameBlacklist probaly needs a similar update and start using hook AuthPluginAutoCreate.

mike.lifeguard+bugs wrote:

Probably related to bug 14474 (Automatically created accounts should not be hidden from CheckUser)

fran wrote:

Should be fixed in r39625 - all accounts created through auth plugins were previously not subject to the AbortNewAccount hooks.

Bug 14474 is actually a different problem, in CheckUser rather than the core, which I'll fix momentarily. :)

mike.lifeguard+bugs wrote:

This seems not to be really fixed. As well, we've switched to using TitleBlacklist for handling this, so I've changed the component accordingly.

http://fr.wikipedia.org/wiki/MediaWiki:Titleblacklist contains .*(?i:e[Il]fix).* <newaccountonly|errmsg=Pseudonyme d’un participant.>

yet -> http://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Journal&user=Elfix_la_p%C3%A9dale

mike.lifeguard+bugs wrote:

*** Bug 16615 has been marked as a duplicate of this bug. ***

Commentary from bug 16615

Gotchas:

  • Calling AbortNewAccount doesn't work this early in the request -- many

extensions expect $wgUser to be set, and it's called as $wgUser is being
unstubbed.

  • CentralAuth has its own AbortNewAccount hook, meaning you need to hack around

and tell that hook that the user is *really* okay to create.

Half-written patch stashed back here. The first gotcha is causing me immense
grief.

brovvnout+bugzilla wrote:

Reopened since it was closed without any apparent reason.

  • Bug 22740 has been marked as a duplicate of this bug. ***

Should be fixed in r67347. See also bug 24756.

(In reply to comment #13)

Should be fixed in r67347. See also bug 24756.

Not completely "fixed" ... see the dependency tree of bug 24756.

Marking this as fixed; r85410 (via bug 24755, bug 24756).

  • (bug 24755) AuthPlugin auto-creation of local accounts can now be aborted by other extensions by handling the 'AbortAutoAccount' hook, similar to the 'AbortNewAccount' triggered by explicit account creations. (They are separate to avoid loops and confusion; auth plugins like CentralAuth need to handle AbortNewAccount separately.