Page MenuHomePhabricator

investigation for ensuring editing with the same credentials
Closed, ResolvedPublic

Description

We need to investigate:

  • What happens if the client user has not logged into the repo before?
  • What are the possible reasons when centralauth doesn't log you in to the repo? (see for example T231209#5445076)
  • What are possible ways out of these cases?
  • What options do we have for recovery on the client after assertuser fails?
  • What happens when sending an edit request without "having been" to wikidata before? Is the right user used then?

Timeboxing it to 1 person for 1 day.

Event Timeline

Lydia_Pintscher moved this task from Backlog to Ready to estimate on the Wikidata-Bridge board.
Lydia_Pintscher triaged this task as High priority.Sep 20 2019, 10:51 AM
Michael claimed this task.Mon, Sep 23, 12:59 PM
Michael moved this task from To do to Doing on the Wikidata-Bridge-Sprint-5 board.

While the situation may happen as described in T231209 and T202028, that the user is only logged into the Wikipedia site with the bridge app, but not into Wikidata, that doesn't seem to be a problem as the login-check is made against central auth and not wikidata itself. Hence the edit is still made on wikidata as the logged-in user without actually being logged-in in wikidata on the browser.

However, the suspected problem mentioned in the description might still arise if someone logs out of Wikidata/Wikipedia after the bridge app was opened (e.g. in another tab). Recovering from that might not be impossible on the technological label, but might be messy on the UX side. E.g. what if someone logs in with a different account than the one which they initially used?

My suggestion would be for now to just request the user to make sure they are logged-in and then to come back, start fresh, and make the edit again.

What already works fine is when starting out as anonymous and then logging in:

  1. Go to wikipedia page and open bridge app from an infobox as anonymous user
  2. open a new tab and log into wikidata
  3. save the edit from the initial tab
  4. ⇒ edit is made as the logged-in user

I have a couple questions regarding this:
-> Do we make central auth as a dependency of DataBridge (especially regarding 3rd parties)? If yes we should somewhere doc (as well as ULS), or?
-> What kind of behavior we consider as a bug of central auth? (like if I am logged in on desktop and change to mobile, my status is gone, or the described behavior of Michaels investigation)
-> I think the bullets 3 and 4 can be reconsidered in T231209 as well, right? (iff we touching the API for userinfos)
-> Do we need more then one option? (I am also okay with the passive approach)

Pablo-WMDE updated the task description. (Show Details)Tue, Sep 24, 10:42 AM
Ammarpad updated the task description. (Show Details)Wed, Sep 25, 12:22 PM
Michael added a comment.EditedWed, Sep 25, 1:09 PM

After playing around with the creation of new users that have never been to wikidata, it seems that the startup API requests to wikidata are enough to create the user there.

So this should not be a problem ✔

I have a couple questions regarding this:
-> Do we make central auth as a dependency of DataBridge (especially regarding 3rd parties)? If yes we should somewhere doc (as well as ULS), or?

Using central auth in 3rd party installations seems to be generally discouraged, because it is complex to set up and maintain. For the purpose of this MVP I would assume that client and repo have in principle access to the same users.

-> What kind of behavior we consider as a bug of central auth? (like if I am logged in on desktop and change to mobile, my status is gone, or the described behavior of Michaels investigation)

Losing the logged-in state when switching to mobile certainly feels like a bug to me, but I'm not sure if it is related to this ticket. The behavior described above is not nice, but it doesn't seem to cause us to bleed IP addresses into the item history.

-> I think the bullets 3 and 4 can be reconsidered in T231209 as well, right? (iff we touching the API for userinfos)

This is response to the following bullet, right?

  • What options do we have for recovery on the client after assertuser fails?

This should be rare, so the simplest approach might be to tell the user to redo the change. Alternatively, we could offer them to continue as anon. I'm skeptical about letting them login in a different tab, because what happens if they login as a different user?

-> Do we need more then one option? (I am also okay with the passive approach)

Not sure to what you are referring here.

I’m not sure what your recommendations for development are, to be honest… basically, we add assert='user' or assertuser=mw.config.get('wgUserName') (not sure which) to the wbeditentity request if the user is logged in locally; rely on CentralAuth to do the right thing™; and if the assert fails, ask the user to log in and try again?

[...] basically, we add assert='user' or assertuser=mw.config.get('wgUserName') (not sure which) to the wbeditentity request if the user is logged in locally; rely on CentralAuth to do the right thing™; and if the assert fails, ask the user to log in and try again?

Yes exactly, that would be my recommendation. I think assert='user' vs assertuser=mw.config.get('wgUserName') is only relevant when considering federation (And if we are considering federation then that would open yet another can of worms.). My suggestion would be to go with assert='user' as this is the least strict assertion that still enforces our central requirement (no IP bleed).

I think assert='user' vs assertuser=mw.config.get('wgUserName') is only relevant when considering federation (And if we are considering federation then that would open yet another can of worms.). My suggestion would be to go with assert='user' as this is the least strict assertion that still enforces our central requirement (no IP bleed).

Hm, on the other hand the current description of T231725 specifically requires edits using the same account, not just that the IP doesn’t leak. But that’s also what we currently do, I think.

So, remaining action item – handle assert failures better?

So, remaining action item – handle assert failures better?

Yeah, I added it to T228066: Error States of Data-Bridge [Tracking]. Not sure if that needs an extra task beyond that? OTOH, we could make this an explicit decision and add it to the product doc?

Pinging @Lydia_Pintscher: If the user logged-out of the wiki in another tab after opening the data-bridge app and thus the saving fails, is it enough for now to tell them to log-in again and redo their thing?

Pinging @Lydia_Pintscher: If the user logged-out of the wiki in another tab after opening the data-bridge app and thus the saving fails, is it enough for now to tell them to log-in again and redo their thing?

Yeah I think that's perfectly acceptable. It should be a pretty rare edge-case anyway.

Lucas_Werkmeister_WMDE closed this task as Resolved.Tue, Oct 1, 11:22 AM
Lucas_Werkmeister_WMDE moved this task from Peer Review to Done on the Wikidata-Bridge-Sprint-6 board.

Okay, I think with that we can close this task.