Allow regular Wikimedians to edit Wikidata or Wikimedia accounts with their regular accounts, without requiring bot passwords

[trnstlntk]

Proposal

@wetneb stated: IMHO doing away with the pop-up entirely, perhaps replacing it with some incentive to use bot passwords in the login form, would be a great move already.

@trnstlntk stated: I would suggest a new page on docs.openrefine.org dedicated to signing into Wikibase(merging the existing docs(1/2)) and replace the two existing paragraphs something pointing to the new page. "Do you have trouble logging in?" "Safer login metods" or something combining those messages.

Original Comment

I notice during tests and demos that 'regular' Wikimedians (the kind of people who, like me, usually only do small batches and who don't write/operate bots) get confused when OpenRefine asks them to provide / get bot passwords or log in with an owner-only consumer Can we simplify this process, or make this even unnecessary somehow?

Additional context

I'm creating this issue because at some point I got the following feedback in my log:

19:20:19.823 [..kibaseapi.ApiConnection] API warning [main]: Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wikimedia.org/> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application. (2283ms)
19:20:19.824 [..kibaseapi.ApiConnection] API warning [login]: Main-account login via "action=login" is deprecated and may stop working without warning. To continue login with "action=login", see [[Special:BotPasswords]]. To safely continue using main-account login, see "action=clientlogin". (1ms)

and while I'm not well-versed in this stuff, it looks as if "action=clientlogin" is something worth looking into?

[Abbe98]

If the issue is mainly concerned with WMF wikis then OAuth using a server side component might be a good solution.

OR would store the access token and secret. The server would store the application token and secret. Shared instances like on PAWS could set a custom OAuth callback URL.

[wetneb]

OAuth requires bundling a secret in the app, and as an open source desktop application this is a difficult thing for us to do. This is the reason why we have not gone in that direction so far. If we wanted to respect the policies around OAuth then this would push us to require that each individual user goes through an OAuth application with the WMF for their own purpose - which basically amounts to using consumer-only tokens (which we already support).

[Abbe98]

OAuth requires bundling a secret in the app, and as an open source desktop application this is a difficult thing for us to do.

OAuth directly targeting the app would be tricky to begin with as the callback URI could vary. I'm, however, suggesting that one uses a server side component to deal with this. The secrets could be stored in environment variables similarly to how most OAuth tools on Tool Forge do it.

[wetneb]

I am not sure how a proxy solves the problem: if you make one, then you are essentially creating an OAuth backdoor into the Wikimedia environment, that applications other than OpenRefine would also be able to use (hence bypassing the OAuth application process). Unless the proxy requires the knowledge of some secret to be used, but then you are back to square one with the problem of bundling that secret in OpenRefine. Also, going through such a proxy has obvious performance and stability downsides (as we see with the reconciliation wrappers).

I think this problem was flagged earlier with Magnus' "WiDaR" tool which was essentially letting any webpage on Toolforge make actions on behalf of users via a single OAuth service (back in the days where we were using the https://tools.wmflabs.org/<tool>/ URL scheme).

[Abbe98]

I am not sure how a proxy solves the problem: if you make one, then you are essentially creating an OAuth backdoor into the Wikimedia environment, that applications other than OpenRefine would also be able to use (hence bypassing the OAuth application process).

The callback URL would point to localhost. Another application running locally on your computer could pretend to make edits from OpenRefine but that's not very different from today's situation. Note that I'm thinking of OAuth 2.0.

Also, going through such a proxy has obvious performance and stability downsides (as we see with the reconciliation wrappers).

I don't think performance would be much of an issue as login isn't an action happening very frequent.

I think this problem was flagged earlier with Magnus' "WiDaR" tool which was essentially letting any webpage on Toolforge make actions on behalf of users via a single OAuth service (back in the days where we were using the https://tools.wmflabs.org// URL scheme).

That was a cookie issue caused by all tools sharing the subdomain, if I remember correctly.

[wetneb]

I still don't get how that would work and comply with the policies, but it's probably because I am not familiar with OAuth 2.0. If the wrapper is only used at login time, then that means OpenRefine would still be making the API calls directly to the Wikibase afterwards, but if the user authenticated via OAuth then I would expect that to require knowledge of the OAuth consumer secret (but so you are saying that OAuth 2.0 does not require that?).

The restriction created by the redirect URL is likely to be an issue as well (people cannot change the port OpenRefine runs on, for instance, and it will break in every hosted environment).

Anyway, given the complexity (and the added requirements for Wikibase users, who would probably also need to deploy such a wrapper on their side), I would prefer using the action=clientlogin API, which is now supported by Wikidata-Toolkit and meant for that use case as far as I can tell. It does not support 2FA yet, but that is unlikely to be a big deal I think.

[wetneb]

@Abbe98 so I just had a conversation with @trnstlntk who would really like to see this fixed. You know more than me about this, so I would really be happy to hand this to you and follow whatever solution you prefer (and you can invoice for it - coordinate that with Sandra).

Otherwise, I might get round to doing this myself (in which case I would just switch to action=clientlogin).

Some other pointers that might be useful:

• previous discussion about OAuth support in OpenRefine: #1612
• similar discussion in the Android Commons App https://github.com/commons-app/apps-android-commons/issues/819 (perhaps things have changed with the introduction of OAuth 2, and this is less relevant?)

[Abbe98]

@wetneb there is no lack off issues with either solution, OAuth for one isn't necessarily even available. clientlogin on the other-hand has less than 1/3 of the usage of login.

@wetneb @trnstlntk to my knowledge there are no plans to remove the deprecated action=login functionality. AFAIK it's deprecated because it will fail on some rare edge cases(like an account needing a password reset).

What about replacing the current in-UI help texts(and the post-login popup) with a "Do you have trouble logging in?"-link pointing to a dedicated documentation page?

[wetneb]

IMHO doing away with the pop-up entirely, perhaps replacing it with some incentive to use bot passwords in the login form, would be a great move already.

[Abbe98]

I would suggest a new page on docs.openrefine.org dedicated to signing into Wikibase(merging the existing docs(1/2)) and replace the two existing paragraphs something pointing to the new page.

"Do you have trouble logging in?" "Safer login methods" or something combining those messages.

[wetneb]

Now that the alert is removed I would say this is purely a documentation issue, so tentatively migrating it to the corresponding repo.