Page MenuHomePhabricator

Allow defining account creation limits for specific groups (e.g. extended-confirmed accounts)
Open, Needs TriagePublic

Description

Making this per the RfC, https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_175#RfC:_Alteration_of_Account_Creation_Limits/Account_Creator_Rights

Primarily, the first question is if it is technically feasible, so if it is, the RfC can be continued as-is. The RfC is for the raising of account creation limit to 10/day for extended-confirmed accounts.

Event Timeline

QEDK renamed this task from Raise account creation limit to 10 for extended-confirmed accounts to Raise account creation limit to 10/day for extended-confirmed accounts.Jun 18 2019, 6:18 AM

See T212667: Create mitigations for account creation spam attack [public task], which lowered the account creation limit per 24 hours per IP from 6 to 4.

@Ankit-Maity, @JJMC89, @Mainframe98: Is this a request to change an *existing* configuration setting? That would be Wikimedia-Site-requests and https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes .
There is wgAccountCreationThrottle in https://noc.wikimedia.org/conf/InitialiseSettings.php.txt but I do not know how one can add a specific group like extended-confirmed? So if this would require someone to do software development first and contribute a patch, and this would make this patch be listed under #MediaWiki-* and not under Wikimedia-Site-requests.

Aklapper renamed this task from Raise account creation limit to 10/day for extended-confirmed accounts to Raise account creation limit to 10/day for extended-confirmed accounts on en.wp.Jun 18 2019, 8:32 AM

IIRC this is controlled by wgAccountCreationThrottle, which can't be modified in a way that allows per-group control. It might be possible to change wgRateLimits's configuration for extended-confirmed using createaccount right to accomplish desired behaviour, not sure if that'll work.

@Urbanecm as far as I can tell, ratelimit doesn't include account creation. Maybe wgAccountCreationThrottle should be converted to a ratelimit?

@Ankit-Maity, @JJMC89, @Mainframe98: Is this a request to change an *existing* configuration setting? That would be Wikimedia-Site-requests and https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes .
There is wgAccountCreationThrottle in https://noc.wikimedia.org/conf/InitialiseSettings.php.txt but I do not know how one can add a specific group like extended-confirmed? So if this would require someone to do software development first and contribute a patch, and this would make this patch be listed under #MediaWiki-* and not under Wikimedia-Site-requests.

That's why I primarily filed this under MediaWiki-Configuration . Pretty sure this needs a MW-side patch before being implemented onwiki.

Then I'm most likely mistaken - I probably confused wgAccountCreationThrottle with wgRateLimits - I'll restore MediaWiki-Configuration as project, as it's becoming pretty clear that this is a request for a new feature, not a change to existing configuration. Apologies for the confusion!

Aklapper renamed this task from Raise account creation limit to 10/day for extended-confirmed accounts on en.wp to Allow defining account creation limits for specific groups (e.g. extended-confirmed accounts).Jun 18 2019, 12:02 PM

Thanks everyone for sharing your technical expertise!

@Ankit-Maity: As this has become a request to develop functionality code I have clarified the task summary.
A request to change the (non-existing) configuration setting for a specific wiki must be separate from this task. That request would currently be unactionable, until somebody contributes the missing functionality code first.

Thanks everyone for sharing your technical expertise!

@Ankit-Maity: As this has become a request to develop functionality code I have clarified the task summary.
A request to change the (non-existing) configuration setting for a specific wiki must be separate from this task. That request would currently be unactionable, until somebody contributes the missing functionality code first.

But I should be correct in understanding that it is implementable, right? The consensus stands till now for the change and it is entirely logical for such a function to exist, I think it is obvious that all users should not have an upped limit but privileged users should be allowed to. An IP-based limit is not defiant of logic sure, but we need a better solution, which is this.

In T225984#5265294, @Ankit-Maity wrote:

But I should be correct in understanding that it is implementable, right?

I'd guess so; in any case someone needs to volunteer and provide a software patch. See https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and https://www.mediawiki.org/wiki/Gerrit/Tutorial if you (or someone else) is interested.

Is any work continuing on this? With issues like T230521 coming up again having more established users (e.g. "extendedconfirmed") not get hit with the default limit would be useful.