Last modified: 2014-03-23 15:20:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42648, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40648 - Can't validate username against blocking extensions AntiSpoof & TitleBlacklist
Can't validate username against blocking extensions AntiSpoof & TitleBlacklist
Status: NEW
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.20.x
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 41849 46308 (view as bug list)
Depends on:
Blocks: 17544
  Show dependency treegraph
 
Reported: 2012-10-01 01:50 UTC by spage
Modified: 2014-03-23 15:20 UTC (History)
6 users (show)

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


Attachments

Description spage 2012-10-01 01:50:56 UTC
The AntiSpoof extension blocks usernames that use certain Unicode ranges, are all letters or punctuation, usernames that "l0ok l1ke" existing usernames, etc. But MediaWiki only hooks into it *while* it is creating a new user account (with the AbortNewAccount hook).  Because MW does not run a hook on User::isValidUserName() or variants like User::getCanonicalName('creatable'), there is no way for a validating account creation form to check if a username will be rejected by AntiSpoof before the user submits it.  This reduces the effectiveness of the improved account creation that the E3 team is exploring.

The simplest fix is to introduce a new isUsableUsername hook that User.php runs from User::isUsableName(), and adapt AntiSpoof (and similar extensions like Minimum Name Length extension, etc.) to respond to it with similar code to its AbortNewAccount hook.
Comment 1 MZMcBride 2012-10-01 02:24:00 UTC
I thought this area of code had been improved somewhat recently. There was a similar issue with the Titleblacklist extension (which is the successor to the Username blacklist extension). There's now an API module that can check a particular username (title) against the title blacklists. I guess something similar for the AntiSpoof extension could be implemented?

Though I think you're right that a more abstract solution is needed.
Comment 2 spage 2012-11-08 01:17:47 UTC
Yes, TitleBlacklist is another one.  This bug affects our A/B test of Account Creation with client-side validation: users may receive username errors when they submit, despite an earlier green checkmark implying username is OK (bug 41849).

I tried to work around the problem by running AbortNewAccount myself when validating username. But many other extensions hook into AbortNewAccount, including ConfirmEdit which fails because the (non-existent) CAPTCHA in the request doesn't match.  The next hack would be to invoke particular extensions' AbortNewAccount handlers myself, but that's about 150 lines of code.

Yes, if each extension had its own API I could invoke the APIs I know about.  It's better for extensions to hook into a CheckValidUsername hook.  And for inter-dependent fields in account creation, we need an AboutToCreateAccount function that lets each extension consider multiple fields in the form much like AbortNewAccount and return error information, but which doesn't actually create the account.

tl;dr: Lots to do to fix this properly.
Comment 3 Ori Livneh 2013-01-13 03:28:32 UTC
*** Bug 41849 has been marked as a duplicate of this bug. ***
Comment 4 spage 2013-03-19 04:31:11 UTC
*** Bug 46308 has been marked as a duplicate of this bug. ***
Comment 5 Simon Walker 2014-03-23 15:20:46 UTC
Related change: https://gerrit.wikimedia.org/r/#/c/87546/ (Add an API module for querying AntiSpoof results)

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


Navigation
Links