Page MenuHomePhabricator
Create Task
Maniphest T16824

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

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 added a project: MediaWiki-extensions-CentralAuth.
• 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

• bzimport added a comment.Jul 15 2008, 7:09 PM

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!

dungodung added a comment.Aug 3 2008, 9:46 PM

Isn't the current confirmation message enough?

• bzimport added a comment.Aug 3 2008, 9:58 PM

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?

• bzimport added a comment.Aug 3 2008, 10:24 PM

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.

• bzimport added a comment.Aug 4 2008, 2:20 PM

ayg wrote:

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

Matanya added subscribers: Legoktm, Matanya.Jun 20 2015, 10:04 PM

@Legoktm this can be closed now, no ?

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

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.

Legoktm added a project: Stewards-and-global-tools.Oct 27 2015, 4:58 PM
Trijnstel subscribed.Dec 18 2015, 2:49 PM
Meno25 unsubscribed.Feb 22 2016, 6:09 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptFeb 22 2016, 6:09 PM
MarcoAurelio removed a subscriber: • wikibugs-l-list.Apr 18 2016, 9:18 AM
MarcoAurelio removed a parent task: T43492: [DO NOT USE] Steward, global sysop and SWMT tasks bugs (tracking) [superseded by #Stewards-and-global-tools].Jan 11 2017, 11:39 PM
Matanya closed this task as Declined.Apr 19 2017, 8:42 PM

per above.

MarcoAurelio moved this task from Backlog to Done on the MediaWiki-extensions-CentralAuth board.Nov 22 2017, 9:47 AM
MarcoAurelio moved this task from Backlog to Done on the MediaWiki-extensions-CentralAuth board.
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL