Page MenuHomePhabricator

Try to connect to central session before temp user creation
Open, Needs TriagePublic

Description

When a temp user visits a new wiki, they might get detached from they central session and appear logged out, due to the issues described in T345249: Mitigate phase-out of third-party cookies in CentralAuth. Clicking on the login link should still work - the workaround in T326281: Attempt top-level central autologin when visiting the login page (to allow autologin when the browser blocks third-party cookies) seems pretty robust so far. But if they start editing a page instead, that creates a temporary user first and does central login only after that, so they would end up as different temp users on different wikis. (I think. I haven't found an easy way to verify it. On beta cross-domain cookies always work, because of T345249#9464539 I think.)

If this is indeed the case, not sure how we could prevent it. For edits via the web form, we could just do a top-level autologin when the user opens the edit form. But for JS-based editors which open without reloading the page, that would be too disruptive. Automatically rename/merge the second temp user when the browser is doing the after-edit central login and the login wiki finds out that they are already logged in as a different users? That seems very complicated.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I can see two ways of handling this:

  • Try to ensure the user is logged in by the time of the edit, by doing a top-level redirect either when they open the editor or when they submit the edit. This is strightforward for the old editor, but not really possible for JS-based editors as far as I can see. (Maybe via a popup window?)
  • After the edit, when we do a central login redirect, special-case the situation where the user is already logged in centrally and do a user merge.

Or we can just ignore the problem and accept that some fraction of temp users will have multiple identities (a fairly large fraction, given the impending Chrome third-party cookie deprecation).