Lucas_Werkmeister_WMDE reopened this task as "Open". Lucas_Werkmeister_WMDE added subscribers: Cparle, Tgr. Lucas_Werkmeister_WMDE added a comment.
I’m afraid we have to reopen this (and other IP Masking tasks in Wikibase aren’t as done as we thought they were either). During discussions with @Tgr, @Tchanders and @Cparle in Slack, it turned out that we should redirect the user to the central login wiki (based on the `TempUserCreatedRedirect` hook, which CentralAuth interacts with) to ensure they’re centrally logged in as well. For Special:NewItem and other special pages that already redirect the user on success, that should be straightforward enough – we just call the hook and adjust the redirect target accordingly. (The hook can be configured such that the resulting URL redirects to the title that we were going to redirect to anyways.) For special pages that don’t redirect the user on success (such as Special:RedirectEntity, T356149 <https://phabricator.wikimedia.org/T356149>), we’ll have to add a new “success” state that the redirect URL can return back to (the page that shows “Q1 was redirected to Q2”), but that should be doable. For interactive edits using the API, I’m not even sure what the UX should be. Suppose an anonymous user has started to edit a bunch of data on an item: F41752637: image.png <https://phabricator.wikimedia.org/F41752637> Now they click one of the “publish” buttons, the API makes an edit, and returns a URL that we should redirect to. What do we do? I think the options we have are: 1. Redirect the user to that URL immediately. 1. Just throw away the other edits they made. 2. Stash the other edits in the `returntoquery` and/or `returntoanchor` of the redirect URL, and hope it fits there (URLs have length limits after all). 3. Stash the other edits server-side, and put some kind of identifier for that stash into the `returntoquery` and/or `returntoanchor`. But now we have to worry where that stash is stored server-side, when it expires, how to protect it against vandalism… 4. Stash the other edits client-side (`localStorage` or similar). 2. Wait until the other edits are done, then redirect the user. As far as I understand the purpose of the redirect, that should be fine-ish – it’s only needed for logging in on other wikis, additional edits on the same wiki should already use the temporary account anyway. But there’s a risk that the user will close the tab before finishing all the edits, and then the redirect never happens. 3. Prevent the user from editing more than one thing at a time (if they’re not logged in), by disabling other “edit” buttons or similar. 4. Don’t redirect at all. In that case, “your temp user identity will be irrecoverably limited to that single wiki” (@Tgr). (For the record, I don’t think all of these solutions are realistic – they’re just theoretic options I can think of. 1.A and 5 are by far the easiest, and I have a feeling they’re almost the only realistic options if we don’t want to block IP Masking for longer than we’d like to. But it’s possible I’m being too pessimistic about how difficult the other options are to implement in the Wikibase UI.) TASK DETAIL https://phabricator.wikimedia.org/T354730 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Arian_Bozorg, Lucas_Werkmeister_WMDE Cc: Tgr, Cparle, GMikesell-WMF, Lucas_Werkmeister_WMDE, dcausse, Tchanders, Michael, Lydia_Pintscher, Arian_Bozorg, Aklapper, ArthurTaylor, Danny_Benjafield_WMDE, Astuthiodit_1, karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, kostajh, Lahi, Gq86, GoranSMilovanovic, QZanden, KimKelting, LawExplorer, JJMC89, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Mbch331, Ltrlg
_______________________________________________ Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org
