Last modified: 2014-09-21 22:10:56 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)
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.
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.
I am following up on this with Frank and others. It is indeed legit and needs to stay open.
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.
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
(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.
> 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.
(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.
Note: this could be done with bug 4995 / bug 14636.
Raymond likely resolved this bug with r72959.
*** Bug 16574 has been marked as a duplicate of this bug. ***
(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?
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 ;)
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.
(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 =(
Another workaround is bug 14636... ;-)
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.
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.
(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.
*** Bug 36367 has been marked as a duplicate of this bug. ***
This should be solved by bug 26992. It's also already mentioned in [[mw:Admin_tools_development]] projects.
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
That's a good news. I'm going to test this extension.
CC'ing Reedy as he has to do all the shell requests that this would remove his need. :-)
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?
(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
(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?
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.
(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
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
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.
Change 109443 had a related patch set uploaded by Parent5446: Changed permission needed for throttle override https://gerrit.wikimedia.org/r/109443
Change 109444 had a related patch set uploaded by Parent5446: Cleanup to ThrottleOverrideHooks::onPingLimiter https://gerrit.wikimedia.org/r/109444
-shell, extension isn't ready for deployment yet. Adding a few blockers that I filed after review.
Change 109444 merged by Legoktm: Cleanup to ThrottleOverrideHooks::onPingLimiter https://gerrit.wikimedia.org/r/109444
Tyler: should this bug still be assigned to you?
Probably not, since I'm not the one reviewing and/or deploying.
Needs security and performance review. I can do the latter. Chris, could you do the security review?
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.
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.
