Last modified: 2012-10-29 16:55:16 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 14629 - Titleblacklist entries with <newaccountonly> should affect automatically created accounts with SUL
Titleblacklist entries with <newaccountonly> should affect automatically crea...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
TitleBlacklist (Other open bugs)
unspecified
All All
: Highest major with 4 votes (vote)
: ---
Assigned To: Brion Vibber
: crosswiki
: 16615 22740 (view as bug list)
Depends on: 24756
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2008-06-24 09:13 UTC by Kalan
Modified: 2012-10-29 16:55 UTC (History)
13 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kalan 2008-06-24 09:13:13 UTC
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.
Comment 1 Andrew Garrett 2008-06-24 09:37:15 UTC
I could swear I fixed this a few weeks ago.
Comment 2 Siebrand Mazeland 2008-08-13 18:20:03 UTC
+testme
Comment 3 Platonides 2008-08-13 18:32:32 UTC
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.
Comment 4 Cometstyles 2008-08-13 20:21:28 UTC
Not fixed yet, we just had a a known troll create multiple "bad usernames" just yesterday, probably needs a fix.
Comment 5 Siebrand Mazeland 2008-08-13 20:33:58 UTC
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.
Comment 6 Mike.lifeguard 2008-08-14 02:43:16 UTC
Probably related to bug 14474 (Automatically created accounts should not be hidden from CheckUser)
Comment 7 Fran Rogers 2008-08-19 02:02:56 UTC
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. :)
Comment 8 Mike.lifeguard 2009-02-19 00:14:48 UTC
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
Comment 9 Mike.lifeguard 2009-02-19 21:28:16 UTC
*** Bug 16615 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Garrett 2009-02-19 21:31:28 UTC
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.
Comment 11 Brownout 2009-10-04 16:28:14 UTC
Reopened since it was closed without any apparent reason.
Comment 12 Andrew Garrett 2010-03-06 13:23:10 UTC
*** Bug 22740 has been marked as a duplicate of this bug. ***
Comment 13 Victor Vasiliev 2010-11-09 18:22:48 UTC
Should be fixed in r67347. See also bug 24756.
Comment 14 Liangent 2010-11-10 05:10:29 UTC
(In reply to comment #13)
> Should be fixed in r67347. See also bug 24756.

Not completely "fixed" ... see the dependency tree of bug 24756.
Comment 15 Brion Vibber 2011-04-05 01:22:49 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links