Page MenuHomePhabricator

Renaming users to a globally-reserved name should verify password/email first
Closed, DeclinedPublic

Description

Author: mike.lifeguard+bugs

Description:
Bureaucrats should be able to rename users to a globally-reserved (ie unified) name /only/ if the accounts belong to the same person. This should use the same logic as merging accounts (Checks password and/or email, IIRC. Change summary as required to fit what it actually does.). In cases where that logic would require the user to enter a password, the rename should be aborted. This ensures that 'crats never unknowingly give the account to someone else.

(Better would be the user is actually asked for the password on their next pageview - if successful, 'crat is notified the rename went through; if unsuccessful the rename is aborted and the 'crat is notified of this. But that is probably very difficult.)


Version: unspecified
Severity: enhancement

Details

Reference
bz14824

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:15 PM
bzimport set Reference to bz14824.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Jul 15 2008, 6:58 PM
vvv added a comment.Jul 15 2008, 7:07 PM

I disagree that it should be only if password/email match, since email isn't always set and password can't be always matched. But we should probably improve warnings so bureaucrats will know that they have to confirm users' identity by themselves

mike.lifeguard+bugs wrote:

Well /some sort/ of check akin to what is done when merging is really needed. But until that can be done, a warning to 'crats that they must confirm this is definitely needed!

Isn't the current confirmation message enough?

ayg wrote:

(In reply to comment #1)

I disagree that it should be only if password/email match, since email isn't
always set and password can't be always matched.

If the user has access to the account, they can always change the password/e-mail so they match. If they don't have access to the account, bureaucrats should not have the ability to give them access. That has historically been a privilege reserved for sysadmins, which is the narrowest possible group that should have it, and it needs to remain that way barring higher-level discussion.

The status quo allows bureaucrats to take over any unmerged account, or more to the point, give it to anyone who asks. I think this is definitely a bad thing that needs to be changed ASAP; bureaucrats do not need this right and should not have it. Brion, what do you think?

mike.lifeguard+bugs wrote:

(In reply to comment #1)
The status quo allows bureaucrats to take over any unmerged account, or more to
the point, give it to anyone who asks. I think this is definitely a bad thing
that needs to be changed ASAP; bureaucrats do not need this right and should
not have it. Brion, what do you think?

I am more concerned with /inadvertently/ giving away access. Unless one knows better, it is perfectly reasonable to assume that the system is doing verification backstage.

vvv added a comment.Aug 4 2008, 7:27 AM

(In reply to comment #4)

The status quo allows bureaucrats to take over any unmerged account, or more to
the point, give it to anyone who asks.

It does not. Newly-renamed account is unmerged, therefore it may not access attached accounts. The largest problem rename may cause is a conflict between two account.

ayg wrote:

Oh, I take it back then. This would be good to have, but not a bug, I agree.

@Legoktm this can be closed now, no ?

MarcoAurelio changed the task status from Open to Stalled.Sep 19 2015, 5:22 PM
MarcoAurelio added a subscriber: MarcoAurelio.

I think this might be closed as @Matanya said. All local conflicts were cleared as part of the SUL finalisation process and local bureaucrats are no longer able to rename accounts at WMF wikis.

Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:09 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 22 2016, 6:09 PM
Matanya closed this task as Declined.Apr 19 2017, 8:42 PM

per above.