Page MenuHomePhabricator

CentralAuth lock/hide should trigger global autoblocks
Open, LowPublic

Description

When a global account is locked there should be an option to allow to automatically global block the IP of the global account as it happens with the autoblock feature on regular wiki blocks. For this to work I guess that CentralAuth should pull the last IP used by the user being locked and submit it to GlobalBlocking anonymized (ie #1234) so the user IPs ain't disclosed in the process to the public.

Currently, since global account locks just terminates the session of the user and makes their password fail, they can continue creating accounts until a steward pulls the IP/CIDR of the user and globalblocks, which increases stewards' work and reduce effectiveness of the tool.

Details

Reference
bz17929

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 10:35 PM
bzimport set Reference to bz17929.
bzimport added a subscriber: Unknown Object (MLST).

(Batch change)

These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.

[Batch change]

Removing Dave McCabe from CC, who I somehow managed to add to the CC list of 12 bugs assigned to me.

Dupe of bug 23114 ?

(In reply to comment #3)

Dupe of bug 23114 ?

Absolutelly not. Bug 23114 talks about *local* autoblocking of suppressed accounts only (lock + suppress). What it is requested here is to globally autoblock the IP(s) of an account when it is locked/lock-hidden/lock-suppressed. This would save us stewards *a lot* of time when dealing with cross-wiki disruption.

Preferably it would be better if we could have a checkbox in the form to select if in that lock we want to activate global autoblock, etc.

I see. You want the ip autolocked even for projects they have never been.

(In reply to comment #5)

I see. You want the ip autolocked even for projects they have never been.

Kind of it happens when you locally block an account with account creation blocked + autoblock. The system could set a global autoblock (global IP block) on the IP. Until global blocking of accounts is possible, this would be very helpful. Thank you.

This depends on creating global blocks. Which could be nice for other tasks, such as global proxy blocking. Although I have also seen meta admins going wild blocking proxys, too.

(In reply to comment #7)

This depends on creating global blocks. Which could be nice for other tasks,
such as global proxy blocking. Although I have also seen meta admins going wild
blocking proxys, too.

For reference, global IP blocking already exists. I'm not sure if this includes ranges (I assume so).

Right. There's GlobalBlocking extension. I did check http://meta.wikimedia.org/wiki/Special:Log before sending comment #7, and I would say the 'Global IP block' option wasn't there... :(

(In reply to comment #8)

For reference, global IP blocking already exists. I'm not sure if this includes
ranges (I assume so).

Yes. IP Rangeblocks (up to /16 ones) can be made with the GlobalBlocking extension, already avalaible to us. However global *b*locking of accounts is not possible at present. See bug 15294 for such a request or possibly bug 18182 too.

(In reply to comment #7)

This depends on creating global blocks. Which could be nice for other tasks,
such as global proxy blocking. Although I have also seen meta admins going wild
blocking proxys, too.

Currently we globally lock plain vandal accounts and plain abusive usernames.

Notwithstanding since the user IP addresses are not affected by global locks (as opposed to a local block with autoblock + account creation blocked) the user can simply continue creating abusive accounts until it hits the account creation per IP limit.

Having the option to autoblock the IP with account creation blocked globally will save us a lot of time having to manually get IPs of vandal accounts and blocking them to avoid ie: switching to another wiki or continue vandalizing, which is very annoying.

Thank you.

Removing ASSIGNED status as no real person seems to be taking care of this (wikibugs is just a mailing list) --> NEW

I suggest too raising the priority to normal. If this existed our work would become easier. Thanks.

+ crosswiki -- Two extensions involved: CentralAuth + GlobalBlocking.

Regards.

quentinv57 wrote:

I've put the priority to normal, as suggested above. We're now waiting for three years.

It would be very nice if this could be processed, even if I agree that it would be time-consuming for developers. But the time you will spend doing this is insignificant regarding the time stewards have lost due to this for now. As Marco Aurelio said above, this will be an amazing gain of time.

Now, when stewards want to globally block a crosswiki vandal, they have to perform the following operations :
1- lock the account
2- give themselves the CheckUser status locally
3- check the user IP
4- block the IP globally
5- remove themselves the CheckUser status
6- lock and delete the stuff the vandal has spread between the time the account has been locked and the IP globally blocked

If we had an auto-block that works, we would no more have to perform the last five points. The gain of time is at least 80%.

Moreover, some vandals know we can't perform checks on projets with local CheckUsers. Indeed, the steward policy forbids us to do this. So sometimes they play with us creating multiple accounts to vandalize, and move from a wiki with local CUs to an other. And we have to wait sometimes for dozens of minutes that a local CheckUser is available to perform the check and to globally block the IP.

I hope I was convincing enough. Thanks for your understanding.

Quentinv57

It looks easy to make an account lock (optionally) insert a globalblock row.
globalblocks table would need a gb_auto column and filtering to not show the ip address in that case.
It's a different approach than the one used in 'normal' autoblocks, but looks more appropiate.

A problem would be that unlocking would need manual unblocking of the ips, though. But seems acceptable.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 27 2015, 4:58 PM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptApr 18 2016, 9:18 AM
Ajraddatz added a subscriber: Ajraddatz.

Copying my explanation from the merged task:
Currently, global locks cannot apply an autoblock and only prevent users from logging in. It would be beneficial to add a "global block" option to this, so that the autoblock can be applied. Currently stewards need to use CheckUser to find the IP address and then separately globally block it, which is public and usually results in an easy connection of account --> IP.

I was testing with centralauth today as a result of [[T47094]], and found out that the "oversight" option of centralauth already does this with a hideuser block. Could a feature be built off of the existing infrastructure to allow for global blocking through centralauth without oversight, in the same way that currently exists? This should be separate from global locking.

Luke081515 added a subscriber: Luke081515.EditedApr 26 2016, 2:34 PM

Maybe we should ask an performance expert, because suppressing auser requires actually a job, which blocks him at all wikis. I'm not a steward, so I can't controll this, but I guess you lock more accounts then hide or suppress accounts, so this can be a performance problem.

And: Before we create this, we have to fix T28476. Otherwise a steward who locks a account in error, and wants to revert it, have to unblock the user in every wiki. Sounds like much fun, if you have to unblock the user at (for example for my account) 394 wikis. :-/

Yeah, the current system is actually quite inefficient and has several issues because it requires sending blocks to all the wikis and these can be hard to manage. Proper way to go forward would be to implement a central blocking system in GlobalBlocking extension as suggested above.

Ok, if so T17294 is a blocker, right? Note that this feature request is also about making the local wiki aware of the IP addresses used by the blocker user on another wiki. Or did you mean that you want to "centralise" the implementation of the IP blocks alone?

The Priority field should reflect reality but does not cause it... So I'm afraid this is de facto low priority (as it was initially).

It would be very nice if this could be processed, even if I agree that it would be time-consuming for developers.

Wondering if someone could bring up this task for the next Community Wishlist round, to give it more attention?

Poyekhali lowered the priority of this task from Normal to Low.Aug 9 2016, 9:38 AM

Per T19929#2315837. Feel free to raise it back to normal if someone is interested in this task.

Stryn added a subscriber: Stryn.Jul 1 2018, 2:08 PM

This is very important for stewards.

Today I locked cross-wiki vandal, and then I went to login.wikimedia.org to checkuser the account, and at this time he had created another account and was already vandalizing before I globally blocked the IP.
{"cc_re__cc_re__cc_by_sa_3_0": ["olicy, and Code of Conduct.</span> \u00b7 <a href=\"https://wikimediafoundation.org/\">Wikimedia Foundation</a> \u00b7 <a href=\"https://foundation.wikimedia.org/wiki/Special:MyLanguage/Privacy_policy\">Privacy Policy</a> \u00b7 <a href=\"https://www.mediawiki.org/wiki/Special:MyLanguage/Code_of_Conduct\">Code of Conduct</a> \u00b7 <a href=\"https://foundation.wikimedia.org/wiki/Terms_of_Use/Phabricator\">Terms of Use</a> \u00b7 <a href=\"https://foundation.wikimedia.org/wiki/Wikimedia:General_disclaimer\">Disclaimer</a> \u00b7 <a href=\"https://creativecommons.org/licenses/by-sa/3.0/\">CC-BY-SA</a> \u00b7 <a href=\"https://www.gnu.org/licenses/old-licenses/gpl-2.0.html\">GPL</a></div></div></div></div><script type=\"text/javascript\" src=\"https://phab.wmfusercontent.org/res/defaultX/phabricator/5a792749/core.pkg.js\"></script><script type=\"text/javascript\" src=\"https://phab.wmfusercontent.org/res/defaultX/phabricator/a98c0bf7/diffusion.pkg.js\"></script><script type=\"text/javascript\" src=\"https://phab.wmfusercontent.org/res/defaultX/phabricator/242aa08b/rsrc/js/phui/behavior-phui-tab-gr"]}