Page MenuHomePhabricator

Add password and username checking JS to core login and signup forms
Closed, ResolvedPublic

Description

Author: usermono

Description:
ENWP had a nice little JS feature that checked the username and password against existing usernames and bad passwords. This was already written & isn't that hard to do, so it should be implemented into the ACUX deployment.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz47685

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:39 AM
bzimport set Reference to bz47685.
bzimport added a subscriber: Unknown Object (MLST).

The new forms are now in core, but these checks were not included in the initial version.

swalling wrote:

This was a part of our testing, but was expensive to build at the time. If you read the spec (https://www.mediawiki.org/wiki/Account_creation_user_experience/Launch) you can see why we made this call.

This enhancement is nice, but even with the work on the account creation API by Brion, is not simple to design, test, and build. To be frank, this project has gone on a looong time, and it may be time to just defer this change in favor of more pressing experimental work.

I'm removing this as a blocker. As Steven said, it's good functionality we would like to have at some point.

However:

  • It does not block rolling out to Commons. It's already at https://commons.wikimedia.org/wiki/Special:UserLogin?useNew=1 as opt-in, and this doesn't block making it permanent (though there are other things that need to be confirmed).
  • It is not on English Wikipedia any more (when it was, it was temporary code in an extension), so it's not an enwiki-only enhancement.

Bumping priority. Having to re-enter the passwords and solve a captcha for each attempt to find a good username is not very user-friendly. I observed somebody giving up registration because of that very recently, and suspect this is not that rare. We want those new editors, so lets not make it harder than necessary.

swalling wrote:

(In reply to comment #4)

Bumping priority. Having to re-enter the passwords and solve a captcha for
each
attempt to find a good username is not very user-friendly. I observed
somebody
giving up registration because of that very recently, and suspect this is not
that rare. We want those new editors, so lets not make it harder than
necessary.

To explain more...

The version Mono refers to was a test version of clientside validation. The A/B test results were pretty good (+4% bump in registrations, which on enwiki alone would be 2-3,000 additional registrations a month).

However, this wasn't good enough for the targets we set (https://www.mediawiki.org/wiki/Account_creation_user_experience/Launch). We set a high standard for how much improvement we wanted in conversion, because with one developer on the project our time was limited.

S Page can chime in more, but the main thing that made creating complete clientside validation a major pain was the presence of extensions like AntiSpoof and Titleblacklist. More at bug 40648. If it wasn't for the blockers in that bug, we could have potentially implemented a simple but effective username/password validation system already.

swalling wrote:

I think this is a duplicate of 17544?

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