Last modified: 2012-04-25 22:05:37 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36188, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34188 - Stewards cannot unlock themselves
Stewards cannot unlock themselves
Status: RESOLVED WONTFIX
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-03 14:22 UTC by Vituzzu@it.wiki
Modified: 2012-04-25 22:05 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Vituzzu@it.wiki 2012-02-03 14:22:15 UTC
I know, it was definitely known but today we performed a scientific trial about self-unlocking: stewards cannot unlock themselves. To me there are two possibilities: allow locked stewards to access centralauth or preventing stewards from locking other stewards...and well, a third one "doing nothing"!
Comment 1 Snowolf 2012-04-25 22:05:37 UTC
I wouldn't consider this a bug at all. This should be normal. First, I don't see how it can be avoived, as lock prevents you from logging on completely. Second, it's the way a compromised or rogue steward account would be dealt with, immediate lock and be done with. Should you happen to lock yourself, as both you and I did, other stewards can unlock. I'm going to mark this as WONTFIX, as this is the intended purpose of the global account lock and as a fix would require substantial rethinking of the feature, ie it becoming global block for user (which is another and different feature). As for disabling the ability to locking other stewards, as I've said above, this is precisely how we deal with a compromised account, and should likely be preserved as such. (compared to stripping of the permissions, it could potentially stop the compromised from changing the emails and/or passwords)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links