Page MenuHomePhabricator

OAuth troubles?
Closed, InvalidPublic

Description

I got a report on Twitter that OAuth login via my widar tool does not work (works for me though). Around the same time, I heard of someone apparently editing under another user name:
https://www.wikidata.org/wiki/Topic:T6nirzoemdk696t9
There was an OAuth issue like this before, IIRC.

Event Timeline

Magnus created this task.Jun 27 2016, 9:24 AM
Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 27 2016, 9:24 AM
Tgr set Security to Software security bug.Jun 27 2016, 8:42 PM
Tgr added a project: Security.
Tgr changed the visibility from "Public (No Login Required)" to "Custom Policy".
Tgr added a subscriber: Tgr.

Just in case, make this a security bug.

Restricted Application removed a subscriber: Zppix. · View Herald TranscriptJun 27 2016, 8:42 PM
Tgr added a comment.Jun 27 2016, 8:43 PM

There was an OAuth issue like this before, IIRC.

That was T124224: I'm editing in Widar under some else his/her account using oauth, when central ID handling was refactored. Nothing changed recently in OAuth though.

It is possibly that this is a problem with normal sessions, ie. the user is actually logged in under the wrong account on the wiki where the grant dialog comes up (and alos on the wiki where WiDaR queries /identify if that's not the same). Specifically, this could be a case of T125283: Users occasionally logged in as different users after SessionManager deployment which happened very rarely and we could never identify the cause or ascertain that it got fixed.

Anomie added a subscriber: Anomie.Jun 28 2016, 12:36 AM

Central IDs don't seem to match up in this case. I also see that both users involved here authorized Widar, and not particularly recently.

Brainstorming potential causes:

  1. A ver just happened to submit the same edits that Innocent bystander did. Not as far-fetched as it may seem if these changes are part of some backlog that both users might be working on.
  2. A bug in Widar where Innocent bystander submitted the edit to be made with Innocent bystander's credentials, but Widar somehow used A ver's credentials instead when actually performing the edits.
  3. Innocent bystander somehow got cookies for Widar that cause it to use A ver's OAuth credentials.
    1. A bug in Widar, possibly caching Set-Cookie headers.
    2. A caching bug in Labs' infrastructure that cached Widar's Set-Cookie headers.
    3. A bug in MediaWiki when Innocent bystander last reauthorized Widar, like T125283.
    4. (Unlikely, but not impossible) A ver borrowed Innocent bystander's computer at some point to use Widar, and didn't log out of Widar.
  4. Something else I'm not thinking of.

I tried to check #1 by assuming this is one of the changes in question and grepping through api.log for queries having Q23672093 in the parameters. I see the edit for the diff itself and one read access a few minutes earlier from tools-webgrid-lighttpd-1407 (i.e. probably Widar), and also an earlier query from an IP address used by A ver for other non-Widar edits. But I see no other API hits with Q23672093 in the parameters from Tool Labs IPs and no hits from IPs used by Innocent bystander, so it's inconclusive as to whether that's actually one of the edits Innocent bystander says they tried to make.

We could check #3 by getting Innocent bystander to tell us what Widar cookies they have, and then (if Widar isn't still just setting it directly as a "tokenKey" cookie) have Magnus extract the corresponding OAuth access token key, which I can then look up in the database to see if it belongs to Innocent bystander or A ver.

Tgr closed this task as Invalid.Jun 29 2016, 8:37 AM

Apparently Brad's first hypothesis is the correct one.

Tgr changed the visibility from "Custom Policy" to "Public (No Login Required)".Jun 29 2016, 8:38 AM
Tgr changed Security from Software security bug to None.
Restricted Application added a subscriber: Malyacko. · View Herald TranscriptJun 29 2016, 8:38 AM