Wikimedia Bugzilla is closed!

to be clarified if this is tool-specific issue or general issue (or maybe general solution needs to be found)

The upload actually *is* coming from the Tool Labs IP in that case, so that's technically correct.

Changing this would require the OAuth-using tool to provide the IP address of the client, which would open us up to malicious tools spoofing source IPs. And doing this is impossible for Tool Labs tools because they don't actually have access to the client's IP (for compliance with the privacy policy).

Though another checkuser performed a check on this same toolserver IP due to an autoblock, which means that if a user is blocked other users (or only bots?) could be affected by it too. I don't think that should happen. And besides, we have lots of edits on this toolserver IP now. Which reminds me of bug 58272 (the localhost, but a bit similar to this since we could have 1,000s of edits on an IP)

(And for the record, I saw also another IP - related to Croptool)

As Brad said, there's not really something we can do here, as we don't want to make the tool providers responsible for passing on the user IPs (also they could spoof it). So please just block the users and ignore the tool labs (or whatever hoster runs the OAuth tools) IP.

The situation with autoblock is indeed scary, though.

As I have replied on the toolserver-l, I don’t see how this could be changed, or how is the situation different to how it worked when the tools ran on Toolserver. See e.g. https://en.wikipedia.org/wiki/Template:ToolserverBot and https://en.wikipedia.org/wiki/Template:Toolserver_IP

The possibility to inadvertently block the whole Tool Labs is unfortunate, but I don’t really see any way to avoid it, when “anybody”’s tools (with “any” code) can run and access WMF projects from there.

The only technical solution for _some_ of the tools, I am able to imagine (very generally), would be to provide a separate server (with its own IP address) running a simple WMF-managed proxy which would somehow pass along the original user IP address (in a trusted XFF header). But this is probably just a crazy complicated half-baked idea.

As others have said, this is how OAuth is intended to work, so I'm going to close the bug since I think the original request as I understand it (have OAuth tools pass on the user's IP address) isn't possible in the case of toollabs apps, and realistically isn't something we can actually enforce. We don't own the app's code, so apps could pass totally random "addresses" in their api calls and we would have no way to know if they were being honest or not.

I'm going to guess that behind this request is that cu's are trying to prove... something via a cu check. Maybe a sockpuppet investigation? And some of the edits were made through the tool. For that, OAuth only works for existing global accounts, so the account creation has to take place form an IP that we can look at.

I'm guessing that behind the investigation is some sort of vandalism, so I'll also add you have basically two ways to address vandalism from an OAuth tool (since the IP address isn't passed on). Block the user (and correct, autoblock would make things difficult, so it should be avoided in that case), or revoke the OAuth tool's key.

If it seems like a single user is abusing the tool, best to just block them directly. If a tools is consistently being abused, then we should revoke the tool's access until the app owner figures out ways to address the abuse. We could probably look into other options, including we could require that they pass on the remote IP in an xff header, and we list the tool as a trusted proxy, as a condition for re-enabling their key. But like I said above, we couldn't prove they were being honest, although it would allow us to track edits by honest OAuth apps.

Feel free to reopen this bug if you think I have the problem wrong, and there's a feature request we can implement. I definitely don't want to see OAuth apps become a vandalism loophole.