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)

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 ✔

In T231887#5518714, @Matthias_Geisler_WMDE wrote:

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?

In T231887#5525667, @Lucas_Werkmeister_WMDE wrote:

[...] 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?

In T231887#5529597, @Lucas_Werkmeister_WMDE wrote:

So, remaining action item – handle assert failures better?

Yeah, I added it to T228066: Step 1: Error States of Data-Bridge [Tracking] (impact: medium). 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?

In T231887#5537096, @Michael wrote:

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.