Page MenuHomePhabricator

Add userrights to MediaWiki Core grants
Open, Needs TriagePublicFeature

Description

Feature summary Allow userrights to be modified by using the API.

Use case(s) : OAuth/Botpassword-backed scripts to lock spambots and block abusive IPs/proxies could implement a feature to add and remove the flood userright at the beginning and end of the script to ensure recent changes and the relevant IRC channels are not flooded by the steward actions.

Benefits : This will improve efficiency by ensuring that flood is applied for the exact right time that is required to perform batch tasks. Currently, a lot of stewards estimate the amount of time that it will take for them to complete a task resulting in them having the flood for longer or shorter than is required. At times tasks can take longer than estimated resulting in the recent changes being spammed if the flood permission expires before the task is done.

Stewards already have a high workload, implementing this can make some of their processes smoother which would beneficial to the team and community. Thanks

Note: Changing user rights via the API is currently possible, but only from an user-script context (or to be more precisely, only if the user is already authenticated). This task is to make the actions=userrights API working for external scripts as well, which are generally authenticated via OAuth or botpassword.

Event Timeline

JJMC89 edited projects, added MediaWiki-Action-API; removed API Platform.
JJMC89 subscribed.

You should be able to use action=userrights.

https://meta.wikimedia.org/w/api.php?action=userrights&format=json&user=Jon%20Kolbert&add=flood&expiry=5%20minutes&reason=example&token=%2B%5C&formatversion=2

{
	"action": "userrights",
	"format": "json",
	"user": "Jon Kolbert",
	"add": "flood",
	"expiry": "5 minutes",
	"reason": "example",
	"token": "+\\",
	"formatversion": "2"
}
Urbanecm reopened this task as Open.EditedNov 28 2023, 11:29 PM
Urbanecm removed a project: Wikimedia-Site-requests.
Urbanecm subscribed.

@JJMC89 Not really though – userrights right is not available as part of any of the existing grants, so all API clients that authenticate by OAuth or bot passwords cannot call action=userrights and expect the result to be something else than "Permission denied". It is only possible to call the API if you're authenticated using your main password, which is supposed to only happen in your browser (or mobile apps) and as such, it does not support a cron-executed script running somewhere and changing user rights via the API.

Even if userrights was a part of a grant, we'd need to do something for groups managed by $wgAddGroups and friends. Granted, that is not an issue for stewards, but it is an issue for virtually everyone else, since only stewards have the full userrights set. Not sure what though – there is no actual right that would guard the userrights changes, unless I'm missing something obvious. It kind of has its own permission control mechanism.

It is technically possible to authenticate via one's real password to the API, but that has couple of disadvantages: (a) you'd need to use action=clientlogin, which is intended for user-handled authentication attempts, not automated ones (b) stewards are required to have 2FA enabled, so 2FA would need to solved on every auth. Taking (a) and (b) together, one would need to store both the password and the 2FA secret on a server for this to work, which is a serious security issue for a lot of reasons (opens the account to hijacking, cannot be invalidated by doing anything else but locking the full account, ...). It is indeed already possible to call the action=userrights API via user scripts, since they run in an already authenticated context, but that was not the use-case of the requestor.

To conclude, I agree with the requestor that it is currently not possible to change user rights via the API from a fully autonomous script/program, at least not in a secure way, using the authentication backends we ask all API clients to make use of. Hence, I am reopening the ticket. I'm also removing Wikimedia-Site-requests, since this is by no ways a site request – core grants should be configured in MediaWiki core, not in WMF config.

Urbanecm renamed this task from Add userrights to grants on metawiki to Add userrights to MediaWiki Core grants.Nov 28 2023, 11:32 PM

Feature summary Allow userrights to be modified by using the API.

There is a disconnect between the task title and the task description feature summary, which is already possible.

mw.Api().postWithToken( 'userrights', {action: 'userrights', format: 'json', user: 'JJMC89', add: 'suppress', reason: 'T352224', expiry: '1 minute'});

API clients that authenticate by OAuth or bot passwords cannot call action=userrights and expect the result to be something else than "Permission denied"

Such clients are not mentioned in the task description, only scripts (presumably JS gadgets or in userspace such as meta:MediaWiki:Gadget-globalmassblock.js).
From my testing, you, unfortunately, don't get any "Permission denied" error when attempting to add a group from an OAuth client. Instead, the response just indicates that there were no changes.

request
{
  "action": "userrights",
  "user": "JJMC89",
  "add": "suppress",
  "expiry": "1 minute",
  "reason": "T352224",
  "token": "<redacted>",
  "format": "json"
}
response
{
  "userrights": {
    "user": "JJMC89",
    "userid": 11935,
    "added": [],
    "removed": []
  }
}

To conclude, I agree with the requestor that it is currently not possible to change user rights via the API from a fully autonomous script/program, at least not in a secure way, using the authentication backends we ask all API clients to make use of.

Changing user groups in a fully autonomous script/program doesn't seem like something we should be letting people do. Running such things is what flagged bot accounts are for, which wouldn't flood.

Changing user groups in a fully autonomous script/program doesn't seem like something we should be letting people do. Running such things is what flagged bot accounts are for, which wouldn't flood.

Stewards have used semi-automated scripts for at least a few years now and the userrights change to add +flood will still appear in recent changes/IRC. Stewards have already been adding and removing the right for some time now, this is just a proposal to do the same thing but more efficiently.

Feature summary Allow userrights to be modified by using the API.

There is a disconnect between the task title and the task description feature summary, which is already possible.

Again, only in user script context; it is not possible in any other context.

API clients that authenticate by OAuth or bot passwords cannot call action=userrights and expect the result to be something else than "Permission denied"

Such clients are not mentioned in the task description, only scripts (presumably JS gadgets or in userspace such as meta:MediaWiki:Gadget-globalmassblock.js).

@kolbert meant steward utility scripts, which are written in Python and make use of OAuth, not user scripts. Granted, that is not clarified in the description. I will change it.

To conclude, I agree with the requestor that it is currently not possible to change user rights via the API from a fully autonomous script/program, at least not in a secure way, using the authentication backends we ask all API clients to make use of.

Changing user groups in a fully autonomous script/program doesn't seem like something we should be letting people do. Running such things is what flagged bot accounts are for, which wouldn't flood.

True. As @kolbert says, this would make sense for autonomous scripts as well, which have the same issue.