Last modified: 2014-04-29 14:54:15 UTC
On English Wikipedia, the following scenario leads to a frustrated editor. I believe this is most likely to apply to occasional editors attempting to become more regular editors; an important group according to the strategic plan. * User attempts to log in. Remembers username, but not password. * User makes 3 failed attempts to guess the password. * User clicks "forgot password" and has a new, temporary password emailed to her. * User enters temporary password, and is prompted to choose a new password. * Upon entering new password, user is informed that she cannot log in right now, because of too many recent failed attempts. I can imagine several general ways to resolve this, but it's not my expertise. I would recommend getting input from a user interface design expert before addressing the issue. However, because of its significance to an important strategic group (i.e., newbies attempting to get through their first 100 edits), I think this should be treated as a high priority fix.
I realize that I didn't state exactly what the problem is. There are two: (1) The editor is not made aware of the consequences of entering an incorrect password too many times. If she knew that the limit was 3 (?), she might have chosen not to guess, but to go to the password reset tool sooner. (2) Once the process is complete, the user is not informed how long to wait, but merely that she has to come back "later." If she has an edit she wants to make now, she either makes it as an IP (undesirable), or gives up (undesirable).
If someone gets locked out for failure to guess their old password, and then they do a password reset, they should get at least one extra chance to log in with the new password.
Giving this to Alolita to consider
This bug has not been touched in at least six months. With this in mind, I've been asked by the bugmeister to bump this bug's priority down for "High". Concerns can be addressed to mah@everybody.org.
This is actually a bug so removing the "enhancement" flag.
I would appreciate it if this could be resolved, or if a workaround from the DB side could be described here. There is no obvious column name indicating where the lock status is set.
So yes, I had a probe at this. The limiting is done via the cache (see incLoginThrottle() in includes/specials/SpecialUserLogin.php), so it would be easy enough to decrement that on password reset. However, we would also need to start rate-limiting password resets, I suspect.
(In reply to comment #7) > So yes, I had a probe at this. The limiting is done via the cache (see > incLoginThrottle() in includes/specials/SpecialUserLogin.php), so it would be > easy enough to decrement that on password reset. However, we would also need > to > start rate-limiting password resets, I suspect. Already done via wgRateLimits (in http://noc.wikimedia.org/conf/InitialiseSettings.php.txt ) right now it's 5/hour/ip
Mmm, interesting. So we should probably shove in a default limit for that. At the moment it's not limited by default. But if you make it very high by default, all the users who have carefully chosen a tight login throttle find their hard work undone. How many rely on the opposite (current) behaviour i.e. an infinite password reset rate, do you think?
This isn't being actively worked on, so I'm setting the priority to reflect reality.
