@Multichill, thanks for the report.

I'm not very familiar with how Widar handles it's sessions, @Magnus, are the authorization tokens kept on the server? Or in the user's session?

Adding @Anomie too, in case this is a possible side effect from the sessionmanager update that was recently released.

Independent(?) report on wikidata: https://www.wikidata.org/wiki/User_talk:Pasleim#Wrong_authorization

I disabled Widar Oauth on Wikidata. My intention was to just do it for myself to not get my account compromised, but this might be for everyone? https://www.wikidata.org/wiki/Special:OAuthListConsumers?name=&publisher=&stage=4

Widar [1.1] (details)

Publisher: Magnus Manske

Description: Wikidata remote editor

Applicable project: All projects on this site

Status: disabled

The current version of Widar is https://www.wikidata.org/wiki/Special:OAuthListConsumers/view/e096baf9fd24cfe180275b52518d7403, still enabled. If we can't find the issue in the next few minutes, I'll disable that one too.

I have not changed anything in WiDaR relating to this for many months. Smells like an upstream issue to me.

Well, I make a new consumer version a few days back. But I can't see how that would trigger a bug in WiDaR either.

It looks like this was probably related to a session change in MediaWiki. We're working through that right now. In the meantime, I agree, doesn't seem like Widar is at fault for this.

Although it does look like widar's authentication isn't setting cookies correctly-- tokenKey and tokenSecret are set with path=0, so never get sent back...

Restarted WiDaR webservice. Trying to reproduce the issue by reloading quick_statements. So far, only correct logins. Trying two different user accounts with different browsers from the same machine in case of IP issue, but works fine so far.

Fixed with https://gerrit.wikimedia.org/r/#/c/265400/ and deployed.

For the record, the problem was that OAuth's auto-detected flag to tell it to look up central IDs wasn't getting auto-detected before SessionManager tried to load the session, so it was using the user with local ID matching central ID stored in the OAuth authorization. The fix was to do the auto-detecting earlier.

In T124224#1949824, @Magnus wrote:

Restarted WiDaR webservice. Trying to reproduce the issue by reloading quick_statements. So far, only correct logins. Trying two different user accounts with different browsers from the same machine in case of IP issue, but works fine so far.

FYI, it was working there probably because group 1 wikis (which include wikidata) were rolled back to wmf.10 at 21:32 UTC.