Page MenuHomePhabricator

Need a way for trusted OAuth apps to make edits from blocked IPs
Open, NormalPublic

Description

In general, Amazon Web Services and other cloud services get blocked on Wikipedia and other wikis. (This is because they have traditionally been used by spammers, and there have been few to no legitimate edits coming from them.)

In addition, multiple Tool Labs tools can get blocked when an admin tries to block a single user or tool.

This means that legitimate OAuth apps that make edits can't be run on AWS (including Heroku, which was the platform my team was developing our app on before we ran into this problem). Perhaps approved OAuth apps (or some subset that have limited potential for abuse) could make edits with already-existing user accounts even from blocked IPs?

Details

Reference
bz72501

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:49 AM
bzimport set Reference to bz72501.
bzimport added a subscriber: Unknown Object (MLST).
Tgr closed this task as Resolved.Jun 23 2015, 7:15 AM
Tgr claimed this task.
Tgr added a subscriber: Tgr.

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.)

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.

Tgr added a comment.EditedJun 29 2015, 8:55 PM

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)
valhallasw renamed this task from Need a way for trusted OAuth apps to make edits for from blocked IPs to Need a way for trusted OAuth apps to make edits from blocked IPs.Jun 30 2015, 10:27 AM
valhallasw reopened this task as Open.
valhallasw removed Tgr as the assignee of this task.
valhallasw updated the task description. (Show Details)
valhallasw set Security to None.
Tgr added a comment.Jun 30 2015, 11:16 AM

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.

Tgr added a comment.Aug 25 2015, 9:52 PM

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 25 2015, 9:52 PM
jayvdb added a subscriber: jayvdb.Oct 7 2015, 5:01 AM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 29 2015, 2:06 PM
Tgr triaged this task as Normal priority.Mar 7 2017, 3:39 AM
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.

Tgr added a comment.Apr 20 2019, 3:10 AM

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.)