Page MenuHomePhabricator

Allow password reset requests to be handled centrally for unified users
Open, MediumPublic

Description

Author: akshay.leadindia

Description:
For unified users, password reset requests dont work on wikis where the user has not visited before. This is because a local account for that user has not been created in that wiki. So, after trying to reset password on that wiki, we get an error "The username '$username' is not registered on this wiki, but it does exist in the unified login system". Even if I wanted to create a new account on this current wiki, I wont be allowed to do so citing that my desired username is very similar to/ same as the existing one. As a user, now I need to remember which wiki I had created that account on or any other wiki which I have visited before (as a logged in user) and then try to reset the password there.

As Dantman suggested we cannot allow creating local accounts on wikis where the user has not visited before because you could abuse that to force MW to create local users on wikis that a user will never go. It could be used both as a form of user harassment and as a way to spam the RC even when blocked.

A better approach would be to improve CentralAuth to allow resetting all passwords centrally for unified users.

Should this approach be approved & if it requires significant efforts, I would be interested on making these changes after I am done with SignupAPI


Version: unspecified
Severity: normal

Details

Reference
bz40050

Event Timeline

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

Not sure if this is still the case, but if it is, AuthManager will make it easy to handle this cleanly: all auth providers will be able handle, ignore or prevent a password change, and the local-password provider will simply ignore (but not prevent) when the local account does not exist. IIRC password resets will be implemented as a special kind of data change and the same principle will apply.

AuthManager doesn't really fix this, since TemporaryPasswordPrimaryAuthenticationProvider needs a local user so it can store the temporary password. We'd have to replace that with something CentralAuth-y (along with other changes) to make it be able to work, or change core to move the user_newpassword field out of the user table and into a table indexed by not-necessarily-existing usernames instead.

OTOH, for WMF wikis we have Meta in $wgCentralAuthAutoCreateWikis so https://meta.wikimedia.org/wiki/Special:PasswordReset should generally be usable.

Also, I note that the default error message for this situation has linked to [[Special:CentralAuth/username]] since August 2013 when T39219 was fixed (although it's currently broken, see https://gerrit.wikimedia.org/r/294732 for the fix), so it's just a matter of clicking the link to find a wiki where it will work.