Last modified: 2014-09-21 22:10:56 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 25000 - Review and deploy ThrottleOverride extension to Wikimedia wikis
Review and deploy ThrottleOverride extension to Wikimedia wikis
Status: NEW
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
https://www.mediawiki.org/wiki/Help:M...
:
: 16574 36367 (view as bug list)
Depends on: 60420 60421
Blocks: 31235
  Show dependency treegraph
 
Reported: 2010-08-31 16:13 UTC by Frank Schulenburg
Modified: 2014-09-21 22:10 UTC (History)
24 users (show)

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


Attachments

Description Frank Schulenburg 2010-08-31 16:13:44 UTC
PROBLEM DESCRIPTION

Whenever people give a Wikipedia workshop for new contributors, participants have problems to create user accounts. These workshops usually take place at computer labs or other places where people access Wikipedia through one IP address.

Mediawiki, however, has a built-in throttle to not allow the creation of more than 6 (?) user accounts from one IP address within a given amount of time. 


SIGNIFICANCE

The problem affect volunteers around the world who offer their free time and effort to recruit new contributors and guide them through their first edits. We have dealt with this problem for many years now and it is time to find a permanent solution to it.  


PROPOSED SOLUTION

Note: Applies to all language versions.

* Option A: Remove the IP throttle.

* Option B: Set the threshold to "100" (people usually won't organize Wikipedia workshops for more than 100 participants)
Comment 1 Platonides 2010-08-31 19:28:33 UTC
There's no way we are going to increase the throttle limit to 100 like this.

a) Workshops can request a temporal increase during the workshop (just fill a bug).
b) If there's a sysop taking part, he can create the accounts without being subject to the throttle.
Comment 2 MZMcBride 2010-08-31 19:45:28 UTC
Re-opening.

While the opening poster's proposed solution is impractical and infeasible, the underlying bug is legitimate. There are legitimate users being impacted by this account creation security measure, so it makes sense to have a bug report to acknowledge this (and hopefully one day resolve it).

Further justification and discussion regarding re-opening this bug is available at http://toolserver.org/~mwbot/logs/%23mediawiki/20100831.txt

One possible solution to this problem is to have a MediaWiki page where local administrators can whitelist IPs and IP ranges from this particular throttle. This is similar to the current system in place for whitelisting IPs and IP ranges from autoblocks.
Comment 3 Rob Halsell 2010-09-02 13:31:04 UTC
I am following up on this with Frank and others.  It is indeed legit and needs to stay open.
Comment 4 p858snake 2010-09-02 13:36:11 UTC
We have a user right that can override the limit (assigned to sysops by default on WMF projects, plus "account creators" at least on the en.wiki), I don't see how this is a problem, No matter what you do, creating multiple accounts from the one location or with the same naming pattern will look spamish. 

The limit is there because of spam issues, I don't see how increasing it will benefit in the long run.
Comment 5 Gurch 2010-09-02 16:20:57 UTC
Two suggestions that would address this:

(1) Apply the account creation limit only to accounts created anonymously, or raise the limit for accounts created by registered users.

Accounts created by registered users while logged-in are attributed to that user in the log, so it is easy for any administrator to see who is responsible for a bulk creation, to block them if it is obviously malicious, and to block all their accounts if one starts misbehaving. With anonymously-created accounts, the creator is not identified, so a checkuser is needed and even they are limited in what they can do.

(2) Implement the feature described in bug 16574 (which I filed in 2008).

This would allow administrators to temporarily disable the account creation limit on a single IP address.

-----

@comment 4: p858snake, the account creator user right as it is currently used is not a solution to this, at least on en.wikipedia.

The right is ONLY available there to the group that uses the private toolserver "request an account" interface[1] to handle accounts requests. It is a requirement to have experience with that interface before the account creator right is assigned, and it is explicitly not given out for any other purpose, such as creating accounts for classroom or event use. And yes, bulk account requests through the "request an account" interface itself are denied too, indeed they are a good way to get your IP address banned. It doesn't help that the user account policy also discourages creating accounts in this way.

[1] http://toolserver.org/~acc/acc.php
Comment 6 MZMcBride 2010-09-03 18:00:26 UTC
(In reply to comment #5)
> Two suggestions that would address this:
> 
> (1) Apply the account creation limit only to accounts created anonymously, or
> raise the limit for accounts created by registered users.
> 
> Accounts created by registered users while logged-in are attributed to that
> user in the log, so it is easy for any administrator to see who is responsible
> for a bulk creation, to block them if it is obviously malicious, and to block
> all their accounts if one starts misbehaving. With anonymously-created
> accounts, the creator is not identified, so a checkuser is needed and even they
> are limited in what they can do.

This isn't tenable. The scenario here is a computer lab full of students/professors/academics/people off the street, for example, all of whom try to register an account and hit the throttle. Requiring a logged-in user to make the accounts would slow everything down considerably.

> (2) Implement the feature described in bug 16574 (which I filed in 2008).
> 
> This would allow administrators to temporarily disable the account creation
> limit on a single IP address.

This really is a duplicate of bug 16574, but I won't mark it as a duplicate. The solution to this bug will very likely be the same solution to bug 16574.

As far as I'm concerned, creating an on-wiki whitelist is the only viable solution currently. It would be similar to the [[MediaWiki:Autoblock whitelist]]. There's no escalation of privilege, as far as I can see, because local wiki admins are already allowed to create as many accounts as they'd like. If the IPs or IP ranges are abused, they can be removed from the list by a CheckUser, presumably.

While I don't think making more configuration pages in the MediaWiki namespace is the greatest idea, it's the current accepted practice and I don't see any reason to not implement it this way for now. I haven't poked at the code yet, but I don't think it should be too difficult to implement.
Comment 7 Platonides 2010-09-03 18:35:24 UTC
> While I don't think making more configuration pages in the MediaWiki namespace
> is the greatest idea, it's the current accepted practice and I don't see any
> reason to not implement it this way for now. I haven't poked at the code yet,
> but I don't think it should be too difficult to implement.

It'd look nicer with an interface similar to the block. Including the expiry time.
Comment 8 MZMcBride 2010-09-03 18:39:05 UTC
(In reply to comment #7)
> > While I don't think making more configuration pages in the MediaWiki namespace
> > is the greatest idea, it's the current accepted practice and I don't see any
> > reason to not implement it this way for now. I haven't poked at the code yet,
> > but I don't think it should be too difficult to implement.
> 
> It'd look nicer with an interface similar to the block. Including the expiry
> time.

Sure, but as far as I know that would require writing a separate UI and creating a set of tables to accommodate the new interface, both of which seem like far more cost than benefit.
Comment 9 Platonides 2010-09-03 22:18:25 UTC
Note: this could be done with bug 4995 / bug 14636.
Comment 10 MZMcBride 2010-09-14 17:03:08 UTC
Raymond likely resolved this bug with r72959.
Comment 11 Platonides 2010-11-08 21:05:54 UTC
*** Bug 16574 has been marked as a duplicate of this bug. ***
Comment 12 Helder 2011-02-03 10:56:01 UTC
(In reply to comment #10)
> Raymond likely resolved this bug with r72959.
That revision was reverted on r76339.

Nonetheless I still see the message
[[MediaWiki:Ratelimit-excluded-ips/pt]]
when I visit the MediaWiki message on Portuguese Wikibooks:
[[b:pt:MediaWiki:Ratelimit-excluded-ips]]

Why is the message not displayed in English, but is displayed other in languages (giving false hopes to users)?

The feature will be needed in the next few weeks, but considering it was reverted, what should we do to let a group students to create their own accounts in the beginning of the classes?

Would we need to request something in the lines of bug 21510? If so, what kind of information should be emailed to OTRS?
Comment 13 Platonides 2011-02-03 19:30:59 UTC
It's probably faster to perform your request directly in bugzilla, marked with the shell keyword.

The code at bug 21510#c1 can be taken as reference. As you see, the parameters used there are the project, the ip from which to lift the limit, what value to set, and the time range in which the greater range should be used.
Things like a good rationale for that change are also appropiate ;)
Comment 14 John Mark Vandenberg 2011-04-28 14:50:10 UTC
Dropping priority as there are alternatives.
* account creator could be easily granted temporarily (for one day)  This will be practical for many scenarios.
  On en.wiki, I'll do it if nobody else will.
* temporarily config change per bug 21510
* A sysop can create the accounts, and could write a bot to do this in the blink of an eye.
Comment 15 Helder 2011-04-28 14:59:35 UTC
(In reply to comment #14)
> * temporarily config change per bug 21510

Well...
When we tried tris for Portuguese Wikibooks (Bug 27172) it didn't work =(
Comment 16 John Mark Vandenberg 2011-04-28 15:18:28 UTC
Another workaround is bug 14636... ;-)
Comment 17 HJ Mitchell 2012-04-02 19:35:32 UTC
I do quite a bit of outreach work under the auspices of Wikimedia UK and this is an issue I've run into a few times, most recently when I had to spend half an hour during an event creating accounts from my account after we hit the limit. It really would be extremely useful if admins were given the ability to allow account creations beyond the throttle, perhaps by whitelisting via an interface page or by something similar to the user rights interface.

Some might say that it's easy enough to have an admin create the accounts, but this can be a logistical nightmare when the admin isn't physically in the room and it can be very time-consuming. Besides which, from an outreach/editor retention point of view, it's highly preferable to have people create their own accounts - it gives a much greater sense of ownership and, in my opinion, would increase the likelihood that somebody would continue editing.
Comment 18 MZMcBride 2012-05-17 02:06:57 UTC
Using Bugzilla/shell users for this is crazy. The code (r72959) was decent enough, I think. It just needs to be pushed out to an extension. Marking this easy.
Comment 19 Raimond Spekking 2012-05-17 07:15:17 UTC
(In reply to comment #18)
> Using Bugzilla/shell users for this is crazy. The code (r72959) was decent
> enough, I think. It just needs to be pushed out to an extension. Marking this
> easy.

I started an extension 7 months ago: http://svn.wikimedia.org/viewvc/mediawiki/branches/raymond/ExemptFromAccountCreationThrottle/

But never had enough time to complete it :-( My previous code (r72959) was hacky by easy, a modern extension is a lot of work.
Comment 20 Helder 2012-05-28 18:55:49 UTC
*** Bug 36367 has been marked as a duplicate of this bug. ***
Comment 21 Nemo 2012-08-24 07:53:49 UTC
This should be solved by bug 26992. It's also already mentioned in [[mw:Admin_tools_development]] projects.
Comment 22 Tyler Romeo 2013-02-07 20:16:38 UTC
I made an extension that fulfills this capability (and also allows overriding of throttles other than just account creation). I'll leave it to somebody else to determine if this resolves this bug.

http://www.mediawiki.org/wiki/Extension:ThrottleOverride
Comment 23 Dereckson 2013-02-07 20:53:59 UTC
That's a good news. I'm going to test this extension.
Comment 24 James Forrester 2013-03-05 21:05:33 UTC
CC'ing Reedy as he has to do all the shell requests that this would remove his need. :-)
Comment 25 Pavanaja U B 2013-05-29 11:34:12 UTC
I also conduct outreach programs sometimes they are conducted in a lab which will have the same IP address to all participants. Hence I have the same request. Can we have the number increased from 6 to a higher number, say, 25?
Comment 26 Nemo 2013-05-29 11:40:25 UTC
(In reply to comment #25)
> I also conduct outreach programs sometimes they are conducted in a lab which
> will have the same IP address to all participants. Hence I have the same
> request. Can we have the number increased from 6 to a higher number, say, 25?

This is a generic bug, don't use it for specific events. Please follow the instructions at https://meta.wikimedia.org/wiki/Mass_account_creation
Comment 27 Alex Monk 2013-12-21 17:15:57 UTC
(In reply to comment #24)
> CC'ing Reedy as he has to do all the shell requests that this would remove
> his
> need. :-)

Are there plans to deploy this extension?
Comment 28 Asaf Bartov 2014-01-24 19:46:40 UTC
I, too, would like to know if that extension has been reviewed yet, and if not, if there's an estimate for when it would be.
Comment 29 Sam Reed (reedy) 2014-01-24 20:03:27 UTC
(In reply to comment #28)
> I, too, would like to know if that extension has been reviewed yet, and if
> not,
> if there's an estimate for when it would be.

No. It's not even on any review queue
Comment 30 MZMcBride 2014-01-24 22:26:42 UTC
Rather than filing a separate bug, I've decided to re-focus this bug on deploying [[mw:Extension:ThrottleOverride]] to Wikimedia wikis. If anyone really strongly disagrees with this action, please revert and clone this bug report.

; Checklist
* Extension page on mediawiki.org: yes
* Bugzilla component: yes
* Extension in Gerrit: yes
* Design review: [probably irrelevant?]
* Architecture/performance review: no
* Security review: no
* Community support: yes
Comment 31 Kunal Mehta (Legoktm) 2014-01-24 22:57:25 UTC
Some review notes:

SpecialOverrideThrottle.php:
* No logging
* Should use a different userright instead of noratelimit
* "The exemption was applied." isn't very friendly, it should probably give some links to somewhere.
* Links like [[Special:OverrideThrottle/127.0.0.1]] should work, and the special page should show past log entries for those IPs
* Need some kind of checking if a restriction is already applied, and whether it should be replaced rather than duplicated.

ThrottleOverrideHooks::onPingLimiter:
* has an assert in it, it should throw an exception or something instead.
* You can check that $user->isAnon() before falling back to the main RequestContext
* $cond doesn't have to be wrapped in a makeList, it already does that internally


Needs some kind of interface to remove exemptions.
Comment 32 Gerrit Notification Bot 2014-01-25 00:21:06 UTC
Change 109443 had a related patch set uploaded by Parent5446:
Changed permission needed for throttle override

https://gerrit.wikimedia.org/r/109443
Comment 33 Gerrit Notification Bot 2014-01-25 00:21:15 UTC
Change 109444 had a related patch set uploaded by Parent5446:
Cleanup to ThrottleOverrideHooks::onPingLimiter

https://gerrit.wikimedia.org/r/109444
Comment 34 Kunal Mehta (Legoktm) 2014-01-25 08:00:39 UTC
-shell, extension isn't ready for deployment yet.

Adding a few blockers that I filed after review.
Comment 35 Gerrit Notification Bot 2014-02-17 21:29:25 UTC
Change 109444 merged by Legoktm:
Cleanup to ThrottleOverrideHooks::onPingLimiter

https://gerrit.wikimedia.org/r/109444
Comment 36 MZMcBride 2014-06-24 04:38:43 UTC
Tyler: should this bug still be assigned to you?
Comment 37 Tyler Romeo 2014-06-24 15:48:36 UTC
Probably not, since I'm not the one reviewing and/or deploying.
Comment 38 Ori Livneh 2014-09-21 03:12:14 UTC
Needs security and performance review. I can do the latter. Chris, could you do the security review?
Comment 39 Bawolff (Brian Wolff) 2014-09-21 04:01:04 UTC
Some thoughts on this extension:

I think there should be different types of rights for different throttles. I have no problem with an admin increasing the account creation limit for a specific IP temporarily. I don't think they should be able to increase the mailpassword limit, ever.

*As far as I can tell, there's no way to remove an override. (I just skimmed code, I haven't tested, might have missed something)

*The sorting on the list page should probably have a secondary sorting field that is unique.

*It should be possible to specify a higher limit, instead of just outright disabling it. We might even want to restrict how high admins can set the setting.
Comment 40 MZMcBride 2014-09-21 22:10:56 UTC
Taking a step back, my understanding is that the primary request here was to be solved by a quick MediaWiki extension, an extension being preferable to further littering MediaWiki core's MediaWiki namespace with weird hacks.

However, if we're going to actually do this in a non-hackish way, we should probably do it in core rather than putting it an extension.

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


Navigation
Links