Page MenuHomePhabricator

Bots cannot access abusefilter API endpoint under new authentication system
Closed, ResolvedPublic


Since using Special:BotPasswords, my bot is unable to query the abusefilters API endpoint. Querying list=abusefilters throws the error API error: code 'abfpermissiondenied', info 'You don't have permission to view abuse filters'. There does not seem to be an "applicable grant" for this at Special:BotPasswords.


Anyone can query for this info, even without an account. Why are bots excluded?

On a hunch, I added sysop rights to the bot on testwiki, and even made my enwiki bot an edit filter manager, and this did not carry over the rights -- but I suppose that's expected since we haven't granted these rights at Special:BotPasswords.

MusikBot has two abusefilter tasks that run twice daily on enwiki, ptwiki and frwiki. Any help in getting this back up is greatly appreciated.

Event Timeline

MusikAnimal raised the priority of this task from to Needs Triage.
MusikAnimal updated the task description. (Show Details)
MusikAnimal added a subscriber: MusikAnimal.

The problem is that there's no grant that grants the AbuseFilter rights, so it's impossible for the BotPasswords- or OAuth-using bot to exercise those rights.

Someone who understands what the various AbuseFilter rights actually do needs to set those rights into $wgGrantPermissions (and possibly add new grant rights-groups to $wgGrantPermissionGroups and i18n messages for those groups). That could be done in operations/mediawiki-config wmf-config/CommonSettings.php, but better would probably be to do so in AbuseFilter itself.

So basically every extension that adds custom permissions to $wgGroupPermissions *also* needs to add them to $wgGrantPermissions?

Unless it doesn't want those permissions to be available to bots using OAuth or BotPasswords, yes.

This isn't particularly new, except that until recently it was $wgMWOAuthGrantPermissions and we were more likely to do it in CommonSettings.php instead of making extensions know about each other. Which is still an option, just less attractive now that grants are in core.

Do we know when bots will be forced to use the new authentication methods? Just hoping this can get sorted out before then. Right now I'm back to using native auth.

Do we know when bots will be forced to use the new authentication methods?

Not really. Even after AuthManager is deployed, action=login with the main account password might continue working for some time.

Just hoping this can get sorted out before then. Right now I'm back to using native auth.

It's an easy change, it just needs someone who understands AbuseFilter's rights well enough to decide which grants would make sense for them.

Easy as in good first task?

The actual code change, yes. It's just adding some entries to $wgGrantPermissions, and maybe adding an entry or two to $wgGrantPermissionGroups with a corresponding i18n message per entry.

Deciding what exactly those entries should be, maybe not so easy.

Change 308289 had a related patch set uploaded (by MusikAnimal):
Add basic AbuseFilter reading writes for OAuth

Change 308289 merged by jenkins-bot:
Add basic AbuseFilter reading rights for OAuth

Anomie assigned this task to MusikAnimal.

Let's call this fixed. If someone wants more advanced rights such as abusefilter-log-private or abusefilter-view-private, they can file a separate task.