Last modified: 2014-11-17 10:36:27 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 15294 - Allow blocking of global accounts
Allow blocking of global accounts
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: High normal with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 50751 (view as bug list)
Depends on:
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2008-08-24 21:45 UTC by Jesse (Pathoschild)
Modified: 2014-11-17 10:36 UTC (History)
28 users (show)

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


Attachments
Attempt to make locking more user-friendly (4.71 KB, patch)
2009-03-12 12:34 UTC, Andrew Garrett
Details

Description Jesse (Pathoschild) 2008-08-24 21:45:46 UTC
Global accounts currently cannot be blocked, so that stewards must lock users out of their accounts to stop them. This is very user-unfriendly, as it does not give an error message. From the user's perspective, their session simply disappears and their password no longer works. This makes account locks impossible to appeal or even understand for the vast majority of users, which exacerbates the situation of false-positive  or legitimate users.

It would be very beneficial to allow stewards to block accounts, with an appropriate you've-been-blocked message when they try to edit or create/unify local accounts.
Comment 1 Mike.lifeguard 2008-12-28 22:01:41 UTC
(In reply to comment #0)
> Global accounts currently cannot be blocked, so that stewards must lock users
> out of their accounts to stop them. This is very user-unfriendly, as it does
> not give an error message. From the user's perspective, their session simply
> disappears and their password no longer works. This makes account locks
> impossible to appeal or even understand for the vast majority of users, which
> exacerbates the situation of false-positive  or legitimate users.
> 
> It would be very beneficial to allow stewards to block accounts, with an
> appropriate you've-been-blocked message when they try to edit or create/unify
> local accounts.
> 

So far as I know, locking was always intended to be temporary until blocking of global accounts could be implemented in a manner similar to global blocking of IPs. What are the chances that Andrew's GlobalBlocking extension can be modified to do users as well?
Comment 2 Andrew Garrett 2009-03-12 12:34:16 UTC
Created attachment 5924 [details]
Attempt to make locking more user-friendly

I attempted to make locking more user-friendly by displaying an error, and succeeded to do it only for new accounts. The Userlogin logic is too deep and confusing to find a sensible way to do it for existing local accounts (I looked at the AbortLogin hook but I have no idea how it works.

It might be sensible to pare down locking to not evaporate a user's session and simply stop edits and new local accounts. This would be functionally equivalent, and much easier to implement.
Comment 3 Mike.lifeguard 2009-03-12 12:37:25 UTC
Well, the whole point of this request is to still have the normal block options like blocking account creation (or not) and blocking email (or not) etc. Presumably this would be easiest to do as an actual /block/ instead of modifying account locking which is already terrible.

That said, explaining what a lock is to locked users is better than leaving things as-is.
Comment 4 Andrew Garrett 2009-03-12 12:41:07 UTC
(In reply to comment #3)
> Well, the whole point of this request is to still have the normal block options
> like blocking account creation (or not) and blocking email (or not) etc.
> Presumably this would be easiest to do as an actual /block/ instead of
> modifying account locking which is already terrible.

Maybe that should have been specified in the original request.

As far as I can tell, blocking global accounts is mostly for people who are definitely vandals, and so block options don't seem strictly necessary. I am, of course, willing to be corrected there.
Comment 5 Mike.lifeguard 2009-03-12 16:47:51 UTC
(In reply to comment #4)
> As far as I can tell, blocking global accounts is mostly for people who are
> definitely vandals, and so block options don't seem strictly necessary. I am,
> of course, willing to be corrected there.
> 

That's true, but only because we don't have diverse block options. What we have is only acceptably used against hardcore vandals and nothing else. We would like to potentially use it for the wider range of issues, but doing that requires the aforementioned versatility.
Comment 6 Jesse (Pathoschild) 2009-03-14 00:08:37 UTC
If it's easier to do without block options, we can do without for now. We can add those later in a separate request, and there's much benefit to displaying a block message.
Comment 7 Andrew Garrett 2009-03-31 14:57:07 UTC
Seems sensible to change locking to only prohibit new account creations and edits, rather than all logins. Thoughts?
Comment 8 Mike.lifeguard 2009-03-31 16:37:21 UTC
(In reply to comment #7)
> Seems sensible to change locking to only prohibit new account creations and
> edits, rather than all logins. Thoughts?
> 

Definitely a good start!
Comment 9 Andrew Garrett 2009-07-03 14:19:34 UTC
CC'd Brion, will want to check with him before drastically changing behavious in such a way :)
Comment 10 Mike.lifeguard 2009-07-03 23:17:28 UTC
(In reply to comment #9)
> CC'd Brion, will want to check with him before drastically changing behaviour
> in such a way :)
> 

I'm not sure when locking accounts became acceptable. This has always been an evil evil thing to do, and was never intended to be a permanent solution. Proper blocking has always been an end goal.
Comment 11 Mike.lifeguard 2009-09-01 05:33:09 UTC
Domas recognizes the insanity of locking accounts in this manner. Perhaps he can push for something to be done from within the development team?
Comment 12 Mike.lifeguard 2009-09-01 06:15:10 UTC
(In reply to comment #9)
> CC'd Brion, will want to check with him before drastically changing behavious
> in such a way :)
> 

From Brion's revert comments in r35958, I think it is clear that this so-called drastic change in behaviour is actually quite expected:

"there's no display of expiry or blocker on Special:CentralAuth" implies that expiries should be a feature

"no overall block list that i can find" implies that there should be such a list

"how does this integrate or compete with GlobalBlocking extension?" implies either
  a) it should integrate, for example with autoblocks at the global level; or
  b) should compete, for example blocking accounts should be part of the global blocking extension rather than in centralauth.
  Neither of those indicates that this change shouldn't be made, and likely implies the opposite - rather strongly, I'd argue. Let's not bother waiting on Brion to confirm the obvious.
Comment 13 Andrew Garrett 2009-09-01 06:18:46 UTC
(In reply to comment #12)
> From Brion's revert comments in r35958, I think it is clear that this so-called
> drastic change in behaviour is actually quite expected:
> 
> "there's no display of expiry or blocker on Special:CentralAuth" implies that
> expiries should be a feature
> 
> "no overall block list that i can find" implies that there should be such a
> list
> 
> "how does this integrate or compete with GlobalBlocking extension?" implies
> either
>   a) it should integrate, for example with autoblocks at the global level; or
>   b) should compete, for example blocking accounts should be part of the global
> blocking extension rather than in centralauth.
>   Neither of those indicates that this change shouldn't be made, and likely
> implies the opposite - rather strongly, I'd argue. Let's not bother waiting on
> Brion to confirm the obvious.

You seem to have misunderstood to what I was referring. I'm referring specifically to the suggestion in comment #7.
Comment 14 SJ 2010-08-23 23:08:00 UTC
Global locks have been increasingly used for normal accounts (cases in which it is 'evil', to use Mike's term, and where blocking would be more appropriate in many ways), which is a pity.  

It would be useful to have this resolved so that more nuanced policies about global blocking can be developed.
Comment 15 p858snake 2011-04-30 00:09:27 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 16 Kudu 2011-09-01 20:27:03 UTC
Also, let's not forget that autoblocking might also be a desired feature.
Comment 17 Sumana Harihareswara 2011-11-14 16:36:50 UTC
It looks like we need both policy decision and technical review of Andrew's patch.  Marking with need-review.
Comment 18 Sumana Harihareswara 2012-08-17 11:09:19 UTC
CC'ing Jack Phoenix per https://www.mediawiki.org/wiki/Admin_tools_development .
Comment 19 bandastouffer 2013-05-06 20:09:55 UTC
I am assigning this extension to employees of the Wikimedia Foundation and Stewards.
Comment 20 Andre Klapper 2013-05-07 09:20:13 UTC
bandastouffer: I don't understand the last comment, could you rephrase?
Comment 21 bandastouffer 2013-05-12 01:53:46 UTC
I would give the ability to block users on all Wikimedia Wikis to Stewards and paid employees
Comment 22 bandastouffer 2013-05-18 18:05:51 UTC
I meant I'd give global user block rights to users in any elected WMF position
Comment 23 bandastouffer 2013-05-18 18:06:26 UTC
I meant I'd give global user block rights to users in any elected WMF position
Comment 24 Kunal Mehta (Legoktm) 2013-05-22 01:02:59 UTC
Once SUL finalization is finished, implementing this should be a lot easier, since you can assume that a username on one project equals the same username on another project. Maybe this can be implemented in the GlobalBlocking extension with a configuration variable to enable blocking of accounts? That would allow wikifarms using $wgSharedDB instead of CentralAuth to also use it.


(In reply to comment #23)
> I meant I'd give global user block rights to users in any elected WMF
> position

This bug is about how to go about implementing such a feature in MediaWiki code, not about who gets the power to use it.
Comment 25 bandastouffer 2013-05-31 21:55:04 UTC
Here is a prototype "you've been blocked message", in text form

         You are currently unable to edit any Wikimedia wiki

     You can still view pages, but not edit, move or create them.

    Editing from $7 has been disabled by $1 across all Wikimedia Foundation wikis, except for Meta, where you may appeal your block.

           This user is blocked for the following reason
                            
                              $2

             The block has been set to Expire: $6

            Note that global blocks do not apply on Meta.
Comment 26 Steven Zhang 2013-06-21 15:04:05 UTC
Change the error message for globally locked accounts would be a good first step here, I think. As I understand it at present, when an account is globally locked, they encounter a message along the lines of "Wrong password" which may cause them confusion (especially if we have globally locked an account to protect it, such as, in a case where the account is suspected to be compromised). Changing the message to something more meaningful along the lines of the below might be a good start:

"Your account has been locked and you are unable to login to, or edit any Wikimedia wiki.

This has been done by $1 for reason $2. For further information on the reasons behind the lock please send an email to stewards@wikimedia.org"

Global blocking definitely seems like a feature that should be implemented when possible after SUL finalisation is done, at present a workaround (locking) is being used that has rather inflexible options. Agree that it should be a feature available only to stewards and staff.
Comment 27 Nemo 2013-08-09 17:19:01 UTC
This is one of the top zero-day deficiencies of CentralAuth and I think everyone is keeping it mind, it's certainly not low priority; setting to High.
Comment 28 Nemo 2013-08-09 17:34:50 UTC
*** Bug 50751 has been marked as a duplicate of this bug. ***
Comment 29 Shinjiman 2013-08-21 13:51:02 UTC
Is that possible to add an option to allow the locked users editing their own talk page? Just like the local block for sysops.
Comment 30 Nemo 2013-08-21 13:54:47 UTC
(In reply to comment #29)
> Is that possible to add an option to allow the locked users editing their own
> talk page? Just like the local block for sysops.

No. Lock is just a hack (or a hammer); global block, requested by this bug, would be the proper way to block global users in the usual way.
Comment 31 dyang304 2013-11-02 23:51:56 UTC
Instead of "Incorrect password entered. Please try again", I'm thinking of two preferable messages: 

1. "Unable to log you in because you account has been locked out, please contact stewards at [[m:Steward requests/Global]] and request unlocking. " 

2. "The specified account is currently locked out and cannot be logged in to. To recover your ability to log in, please make an unlocking request for your account at [[m:Steward requests/Global]]. " 

Note: All wiki markup will be used.  

Also, as Nemo pointed out, maybe we could enable block settings for global Blocks of accounts, maybe like talk page editing, so that local sysops can locally disable global blocks, e-mail access, and account creation status (enabled or disabled).

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


Navigation
Links