Last modified: 2014-09-03 23:50:11 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 T72058, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70058 - Ajax check for username availability is not aware of global accounts that are not attached to the local wiki
Ajax check for username availability is not aware of global accounts that are...
Status: RESOLVED DUPLICATE of bug 64728
Product: MediaWiki
Classification: Unclassified
User login and signup (Other open bugs)
1.24rc
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-26 19:19 UTC by Bryan Davis
Modified: 2014-09-03 23:50 UTC (History)
2 users (show)

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


Attachments

Description Bryan Davis 2014-08-26 19:19:31 UTC
The check in resources/src/mediawiki.special/mediawiki.special.userlogin.signup.js that attempts to help the user choose an available username is not aware of CentralAuth accounts that have not been attached to the local wiki. This is due to the use of /w/api.php?action=query&list=users to power the check.

Example:

* http://en.wikipedia.org/w/api.php?action=query&list=users&ususers=BryanDavis
* http://fr.wikipedia.org/w/api.php?action=query&list=users&ususers=BryanDavis

The conflict will be noticed when the form is submitted, but it would be nicer if users were warned about global user conflicts by the pre-submit validation.
Comment 1 Bartosz Dziewoński 2014-08-26 19:28:29 UTC
Known issue, the functionality was added in 74b222230 with the comment:

> The way this is done (via action=query&list=users API) means that we
> can't check for all possible error conditions, both for the username
> (e.g. these enforced by extensions like AntiSpoof) and other parts of
> the form (e-mail, password…) – these are still handled server-side
> only. Thus we intentionally never say that whatever the user typed in
> is valid – we only warn when we know it's not.
> 
> Doing this "properly" would require some reworking of the internals of
> the signup process and this way is already a huge improvement.

Basically, this would probably be best solved with a "dry run" mode for the registration form.
Comment 2 Bartosz Dziewoński 2014-08-26 19:31:28 UTC
(Hmm, this might be a duplicate/dependency of bug 64728. Definitely related.)
Comment 3 Bryan Davis 2014-08-26 19:47:31 UTC
This is definitely a dup of bug 64728

*** This bug has been marked as a duplicate of bug 64728 ***

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


Navigation
Links