Page MenuHomePhabricator

Support subnet-based throttling in Throttler
Open, LowestPublic

Description

Author: dasch

Description:
I thin it could be useful to restrict usercreation from ip or subnet. This maybe could be done in $wgRateLimits.
I often observe mass creation of user on my wiki and would like to prevent this.


Version: 1.22.0
Severity: enhancement

Details

Reference
bz48373

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:29 AM
bzimport added a project: MediaWiki-General.
bzimport set Reference to bz48373.

Related URL: https://gerrit.wikimedia.org/r/65867 (Gerrit Change If77868ffd7eb5d400d839d78ab2f401fa872f0ed)

What about specific user rights for all the other throttle types? The account creation throttle was supposed to even be moved into the ping limiter entirely.

Account creation is where the need is greatest, we need an option to raise it or remove it for members of the account creation usergroup, without having to grant them noratelimit, since they should be subject to all the other rate limits. Independently, it would be nice to raise the limit on page moves for members of a trusted usergroup, especially in light of T76263, but not to remove it completely.

What may be done to handle both cases is adding a 'high' entry for the move and account sub-arrays in $wgRateLimits and create userrights highratelimit-account and highratelimit-move which would check those and override any other.

For example on the English Wikipedia, highratelimit-account would be granted to the account creator usergroup, and we would set $wgRateLimits['account']['high'] = array( 100, 86400) to raise account creations from 10 to 100 per day, or $wgRateLimits['account']['high']= null to remove the limit. On the English Wikibooks, highratelimit-move may be granted to reviewers and we would set $wgRateLimits['move']['high'] = array( 25, 60) so that they could make 25 moves per minute instead of 10.

If needed, any other high rate limit userright for another specific action could be added the same way.

What about specific user rights for all the other throttle types? The account creation throttle was supposed to even be moved into the ping limiter entirely.

Account creation is where the need is greatest, we need an option to raise it or remove it for members of the account creation usergroup, without having to grant them noratelimit, since they should be subject to all the other rate limits. Independently, it would be nice to raise the limit on page moves for members of a trusted usergroup, especially in light of T76263, but not to remove it completely.
What may be done to handle both cases is adding a 'high' entry for the move and account sub-arrays in $wgRateLimits and create userrights highratelimit-account and highratelimit-move which would check those and override any other.
For example on the English Wikipedia, highratelimit-account would be granted to the account creator usergroup, and we would set $wgRateLimits['account']['high'] = array( 100, 86400) to raise account creations from 10 to 100 per day, or $wgRateLimits['account']['high']= null to remove the limit. On the English Wikibooks, highratelimit-move may be granted to reviewers and we would set $wgRateLimits['move']['high'] = array( 25, 60) so that they could make 25 moves per minute instead of 10.
If needed, any other high rate limit userright for another specific action could be added the same way.

That is a bad idea. There have been times as an account creator that I've found the backlog excessively high for one reason or another and I believe I have created over 100 accounts in a day through the ACC tool interface at least a time or two. There needs to be no limit, or the limit needs to be set so excessively high that no account creator could hit it in good faith.

What about specific user rights for all the other throttle types? The account creation throttle was supposed to even be moved into the ping limiter entirely.

Account creation is where the need is greatest, we need an option to raise it or remove it for members of the account creation usergroup, without having to grant them noratelimit, since they should be subject to all the other rate limits. Independently, it would be nice to raise the limit on page moves for members of a trusted usergroup, especially in light of T76263, but not to remove it completely.
What may be done to handle both cases is adding a 'high' entry for the move and account sub-arrays in $wgRateLimits and create userrights highratelimit-account and highratelimit-move which would check those and override any other.
For example on the English Wikipedia, highratelimit-account would be granted to the account creator usergroup, and we would set $wgRateLimits['account']['high'] = array( 100, 86400) to raise account creations from 10 to 100 per day, or $wgRateLimits['account']['high']= null to remove the limit. On the English Wikibooks, highratelimit-move may be granted to reviewers and we would set $wgRateLimits['move']['high'] = array( 25, 60) so that they could make 25 moves per minute instead of 10.
If needed, any other high rate limit userright for another specific action could be added the same way.

That is a bad idea. There have been times as an account creator that I've found the backlog excessively high for one reason or another and I believe I have created over 100 accounts in a day through the ACC tool interface at least a time or two. There needs to be no limit, or the limit needs to be set so excessively high that no account creator could hit it in good faith.

This is a config variable that can be set specifically for each wiki, I used 100 as a random example, the default should be null so there would be no limit at all. Which limit to use, if any, can be discussed at enwiki or at the appropriate configuration change bug.

Change 266449 had a related patch set uploaded (by Cenarium):
Add $wgRateLimits types ip-all and subnet-all

https://gerrit.wikimedia.org/r/266449

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 26 2016, 1:10 AM

Change 266450 had a related patch set uploaded (by Cenarium):
Move account creation throttle to ping limiter

https://gerrit.wikimedia.org/r/266450

Change 266449 merged by jenkins-bot:
Add $wgRateLimits types ip-all and subnet-all

https://gerrit.wikimedia.org/r/266449

Is https://gerrit.wikimedia.org/r/#/c/266450/ still a valid change and is someone willing to rebase, review and submit it?

Bawolff added a subscriber: Bawolff.Aug 5 2016, 7:23 AM

Note, the current status is that:

  • Most users and anons are limited to creating at most 6 accounts in 24 hours (4 for hebrew language projects, no limit for id.wikipedia.org)
  • Account creators, bots, and admins are exempt from this limit.

Change 266450 abandoned by Cenarium:
Move account creation throttle to ping limiter

Reason:
Now that the throttling is handled by OAuth, it's up to the OAuth throttle. Support in OAuth to lower limits for users in a given group should be added, and maybe subnet-based throttling.

https://gerrit.wikimedia.org/r/266450

Cenarium renamed this task from add createuser to $wgRateLimits to restrict usercreation from IP or Subnet to Support subnet-based throttling in OAuth.Sep 20 2016, 5:30 PM
Cenarium removed Parent5446 as the assignee of this task.
Cenarium lowered the priority of this task from Low to Lowest.
Cenarium removed a project: Patch-For-Review.
Cenarium added a subscriber: Anomie.
Cenarium renamed this task from Support subnet-based throttling in OAuth to Support subnet-based throttling in AuthManager.Sep 20 2016, 5:49 PM
Cenarium renamed this task from Support subnet-based throttling in AuthManager to Support subnet-based throttling in Throttler.Sep 21 2016, 3:38 PM