Page MenuHomePhabricator

Client-side validation of the username availability (done) and that password meets requirements
Closed, ResolvedPublic


When a user tries to create an account, if the captcha is successful but the username is already taken or the passwords doesn't match, the user has to take the test again. This is bad, especially since captchas are far from user friendly.

So, why not keep in mind that the user passed the captcha ?

Version: unspecified
Severity: enhancement
See Also:
T58025: AJAX validation of username for password reset



Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:30 PM
bzimport set Reference to bz17544.
bzimport added a subscriber: Unknown Object (MLST).

Seems doable, using similar counter and expiration logic to ConfirmEdit/Captcha.php's triggerUserLogin(). There are probably security implications I overlook.

Were we to do client-side validation in Create account (see ACUX-3 in ), then users would be informed of_some_ form problems before filling out the CAPTCHA, lessening the need for this enhancements.

Indeed, client-side validation of the username availability and password seems like a much better way to do it.

swalling wrote:

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

In addition to the captcha, the user also has to re-enter the password twice. The only bit of previously-entered information that currently survives is the mail address.

The username also survives.

(In reply to comment #5)

The username also survives.

Yeah, although you'll normally change it when you are looking for an unused username.

There is nothing to validate for the email, since more than one account can have the same email.

If I try to register an existing username, I get a warning displayed: Account creation error Username entered already in use. Please choose a different name. So that part seems to be fixed nowadays? Should the task summary be updated?

The password validation (very same password entered twice) seems to still be valid though - need to enter the passwords and capture again.

The password strength aspect seems to be covered by T5348 already.

Mattflaschen-WMF renamed this task from Client-side validation of the username availability and that password meets requirements to Client-side validation of the username availability (done) and that password meets requirements.Mar 25 2015, 5:27 AM
Mattflaschen-WMF set Security to None.
Danny_B moved this task from G to Processes on the Accessibility board.Jan 22 2016, 10:51 PM
Tgr updated the task description. (Show Details)Nov 18 2016, 1:21 AM
matmarex closed this task as Resolved.May 29 2017, 5:10 PM
matmarex assigned this task to Anomie.

Both of the changes have been merged and this appears to work correctly.