| The_RedBurn | |
| Feb 17 2009, 11:36 PM |
| F8211253: image.png | |
| May 29 2017, 5:10 PM |
| F8211255: image.png | |
| May 29 2017, 5:10 PM |
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
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 https://meta.wikimedia.org/wiki/Research:Account_creation_UX ), 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.
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.
(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.
