[go: nahoru, domu]

Page MenuHomePhabricator

Design request: Central Login Design Review and Recommendations
Open, Needs TriagePublic

Description

Due to upcoming changes to how browsers handle cookies we will need to send users to a different domain to log in. The platform team has a demo running on how this might work.

There was a request for design to review this design and user flow and provide a review with any recommendations.

Event Timeline

The design teams initial review can be found here

nayoub subscribed.

There are two design aspects of this (that I'm aware of right now). One is the one that has been discussed, that we might want to replace the fullscreen login form with a popup or iframe modal. The other is that the URL used to share cookies will become user-visible (unless we go with the iframe modal, which has technical disadvantages). So when interacting with the login form, the user will see something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious ("wikimedia.org" has limited brand recognition compared to "wikipedia.org", technically sophisticated users will maybe think the presence of en.wikipedia.org (used to identify from which wiki the user started the login process) is a phishing trick).

...something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious...

Can we just use numeric ids or short hashes that map to the various project domains?

We would have to maintain another mapping (besides domain <=> DB name and domain <=> site/lang) then. Other than that, it's straightforward.

The user will see something like https://sso.wikimedia.org/en.wikipedia.org/wiki/Special:Userlogin which is potentially confusing or suspicious ("wikimedia.org" has limited brand recognition compared to "wikipedia.org", technically sophisticated users will maybe think the presence of en.wikipedia.org (used to identify from which wiki the user started the login process) is a phishing trick).

My guess would be that technically sophisticated users are able to link wikimedia.org with Wikipedia given that we already load resources from wikimedia.org (CentralNotice, Commons images, etc.) on every request (previously also bits.wikimedia.org). I think if we're worried about phishing concerns, which is reasonable, it would be good to avoid acronyms and jargon like "sso" and use a more accessible term "login" or "accounts" (hopefully I'm not trying to re-open a closed bikeshed).

It's an open bikeshed! Others have recommended suggested "accounts" too. (login.wikimedia.org is already in use.) It's more understandable but also not very accurate since the domain will not be used for account management in general.

well if the shed is open... could SSO be de-acronymed to single-sign-on.wikimedia.org?

Yeah we could do that. Or we could use something like authentication.wikimedia.org.

We'll go with "sso" for the Beta cluster version (T365162) since the code is already written for that, but it's trivial to change later. We won't need to settle on a final name for a while, since deciding T363695 will take some time; at this point it's also possible we won't be able to use a new domain at all, and will use login.wikimedia.org with a very different implementation. So not worth spending too much effort on the name yet. But we'll circle back once we are certain a new domain is needed, since the naming seems like primarily a UX question.

Alternatively we can just use login.wikimedia.org with a different code path like https://login.wikimedia.org/login/enwiki