In T74501#1391211, @Tgr wrote:

ipblock-exempt is part of the basic grant so every OAuth application has it.

More specifically, if you give the account the app is using a group that gives the ipblock-exempt right then it'll be able to take advantage of the right.

There's no way to allow any arbitrary user using the OAuth app to have ipblock-exempt if their account doesn't already have it.

In T74501#1411392, @Anomie wrote:

There's no way to allow any arbitrary user using the OAuth app to have ipblock-exempt if their account doesn't already have it.

Yes, but making OAuth applications ipblock-exempt without any further consideration is probably not a good idea as there is no other way to block an application that is misbehaving on a single wiki.

Some things that could be done:

• abort all autoblocks on OAuth actions
• provide a way for admins to block an OAuth application (which would only effect a single wiki); making OAuth ipblock-exempt should not be a problem after that
• trust OAuth apps to set X-Forwarded-For so that ipblocks would be based on the IP of the user, not the IP of the tool. This would force tools which do non-immediate actions to store IP addresses and associate them with user accounts, though, which would be bad.

In T74501#1411568, @Tgr wrote:

• trust OAuth apps to set X-Forwarded-For so that ipblocks would be based on the IP of the user, not the IP of the tool. This would force tools which do non-immediate actions to store IP addresses and associate them with user accounts, though, which would be bad.

I don't think we should require all OAuth apps to set XFF, but if one did and got listed in the TrustedXFF list, I think that would work

In T74501#1391211, @Tgr wrote:

ipblock-exempt is part of the basic grant so every OAuth application has it. (Besides pre-blocked cloud providers, it's also necessary to avoid the whole tool getting blocked when a blocked user tries to use an OAuth action.)

Aha. On WMF wikis, ipblock-exempt is standard for autoconfirmed users, right? So effectively, an IP block will require users of the OAuth tool to be autoconfirmed, which ((I think) is not unreasonable. There are a few use cases I can think of where it can be a problem, though:

• a tool, e.g. for wiki loves monuments, aimed at new users, which would not be autoconfirmed yet
• a tool which edits on multiple wikis, one of which has not been actively visited by the user (e.g. creating user pages, although that specific example is no longer valid with the shared user pages)

In T74501#1413161, @valhallasw wrote:

Aha. On WMF wikis, ipblock-exempt is standard for autoconfirmed users, right? So effectively, an IP block will require users of the OAuth tool to be autoconfirmed, which ((I think) is not unreasonable. There are a few use cases I can think of where it can be a problem, though:

Don't think so. Normally it is given to bots and admins.

A possible fix for the (slightly more generic version of the) problem would be T110249-

In T74501#1411568, @Tgr wrote:

• trust OAuth apps to set X-Forwarded-For so that ipblocks would be based on the IP of the user, not the IP of the tool. This would force tools which do non-immediate actions to store IP addresses and associate them with user accounts, though, which would be bad.

See also T159889: Per-consumer XFF trust settings

Note that CropTool was down for 20 hours today, causing 322 failed crop attempts, because an autoblock happened to include the Toolforge IP used by CropTool. Luckily, this doesn't happen often, I think the last time was in 2014, but as a maintainer it's frustrating when it happens.

OAuth is currently not resourced, but there's a team working on blocking tools so realistically you might have better chances for improving things from that direction. Autoblocks of Toolforge IPs probably should not happen, after all, it's sufficiently important and trusted infrastructure that it should only be blocked by someone who is conscious of what they are doing.

(Which only half-solves the problem as admins still need a way of dealing with vandals editing through Toolforge tools. So at some point we'll need the XFF thing.)

In T74501#5125487, @Danmichaelo wrote:

Note that CropTool was down for 20 hours today, causing 322 failed crop attempts, because an autoblock happened to include the Toolforge IP used by CropTool. Luckily, this doesn't happen often, I think the last time was in 2014, but as a maintainer it's frustrating when it happens.

The autoblock issue was fixed with https://commons.wikimedia.org/w/index.php?title=MediaWiki:Block-autoblock-exemptionlist&diff=prev&oldid=346495333

Using the block-autoblock-exemptionlist message seems to fix this task, but not a nice use case to edit the message for new apps.