Page MenuHomePhabricator

Rewrite URLs when using the shared login domain
Closed, ResolvedPublic

Description

T363695: Create a Wikimedia login domain that can be served by any wiki proposes a shared domain that can be served by any wiki, and is restricted to authentication workflows (login, signup, credentials change). The restriction means that we want most links (e.g. terms of use, links in customized i18n messages) to not use the shared domain but send back the user to the normal domain of the wiki where they started authentication. But links that are part of the authentication flow (e.g. switching from login to signup) should not be changed. We need to figure out the way to do that.

This has a strong overlap with figuring out which links should open in the same window in display=popup mode (T362706: Permit displaying the login / signup page in a popup or iframe) which was eventually handled via a HTML post-processing step in SkinAuthenticationPopup::openLinksInNewWindow(). Probably we could use a shared mechanism for both (and for indicating which links are in-flow vs. out-of-flow for authentication).

Event Timeline

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

So there are two parts to this: deciding which links we want to allow/disallow, and modifying them to do so.

Regarding the modifying:

I looked into doing that on the SSO domain, and it would require adding some ugly hooks to MediaWiki. The popup could do that, because it's implemented as a custom skin, and the skin ultimately has final control over all of the HTML output. The SSO domain just uses the default skin (which could be Vector, Vector-2022, or Minerva, or the popup skin too). There is no hook that would give us the same capability in a regular extension, and I'm not sure if it would be a good idea to add one – we've been trying to avoid adding hooks that let you do too much, and this could be considered too much.

I thought about other approaches, and I realized that the GetLocalURL hook would be another option. It lets us rewrite all URLs generated by MediaWiki, before it puts them into the href attribute (or elsewhere – worth noting that this would also affect e.g. form action attributes). We couldn't do that in the popup, because we needed to change the target attributes.

Regarding the deciding:

Yeah, it was overlap with the popup thing… but it also has overlap with deciding which pages we want to allow accessing on the SSO domain. We already have a list called ALLOWED_SPECIAL_PAGES in CentralAuth. Could we just rewrite all links to any other page?

In fact, I like using a list of allowed special pages much more than the popup's approach of marking individual links that are allowed. Maybe we should consider doing that in the popup as well.

(If we use the GetLocalURL hook, then the approach used in the popup won't work, because that hook doesn't have any information about which link on the page we're currently rendering.)


I wrote a proof-of-concept using the GetLocalURL hook, but this is still fully up for discussion if we want to try the other (or yet another) approach.

Change #1071268 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Rewrite URLs when using the shared login domain

https://gerrit.wikimedia.org/r/1071268

What's an example of a link that this patch is meant to leave pointing to the SSO domain? I understand that in theory that's any auth-related URL, but where do we display such a link within an auth page on the SSO domain?

Altering non-auth links is important since otherwise those links will serve a permission denied error (as we deny using SSO for other purposes, to avoid those links spreading and becoming common/normal, not even with a redirect). But, altering auth-links is less obvious to me in terms of use case. Presumably links like "Create account" or "Log in" are less an issue since 1) you'd have already clicked on those to get here and 2) if you do arrive on them on the local wiki, CentralAuth would redirect you to where you need to be.

I think avoiding the redirect is a nice performance optimisation, and I don't question the patch as a worthwhile improvement either way. What I'm looking for is things I may've missed or that I don't know about yet.

Yeah, it was overlap with the popup thing… but it also has overlap with deciding which pages we want to allow accessing on the SSO domain. We already have a list called ALLOWED_SPECIAL_PAGES in CentralAuth. Could we just rewrite all links to any other page?

As long as the link is associated with a title, that looks like a very robust approach - if the title is not listed there, it will result in a permission error anyway, and I can't think of any reason why we'd want to link back to the original wiki for a special page that's available locally. (We'd have to be careful when generating redirects, but at least the current auth flow does not involve the server generating an URL to redirect to when handling the SSO request; the return URL is pre-generated and passed in.) I guess this task is really only about such links, with assets etc. covered elsewhere.

What's an example of a link that this patch is meant to leave pointing to the SSO domain? I understand that in theory that's any auth-related URL, but where do we display such a link within an auth page on the SSO domain?

Form actions (but note that not all form actions - if we use a full skin, we want the search form to take the user back), login->signup switch button, language selector links on multilingual wikis, mobile/desktop switch in the footer, (eventually) the link to the password reset page. Maybe captcha image URLs (which would work either way, but for logging and ad-hoc security mitigation purposes it might be nice to be able to associate them with the login session). I think the GetLocalURL proposal would cover all of those.

Altering non-auth links is important since otherwise those links will serve a permission denied error (as we deny using SSO for other purposes, to avoid those links spreading and becoming common/normal, not even with a redirect). But, altering auth-links is less obvious to me in terms of use case. Presumably links like "Create account" or "Log in" are less an issue since 1) you'd have already clicked on those to get here and 2) if you do arrive on them on the local wiki, CentralAuth would redirect you to where you need to be.

Special:CreateAccount on the local wiki doesn't work since from that wiki's POV creating a new user is also just a login (the account creation happens on the SSO domain). Maybe we should fix that, a BeforePageDisplay or SpecialPageBeforeExecute hook could redirect from there to Special:Userlogin&sul3-type=signup or whatever we'll end up using. The mobile -> desktop switch would also break I think, because it would put the mobile cookie on the wrong domain. The rest would work - language selectors would just result in an extra redirect, the password reset page and captcha images don't redirect but would work on either domain.

Change #1072627 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Rewrite URLs to mobile when using mobile view on shared login domain

https://gerrit.wikimedia.org/r/1072627

Change #1071268 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Rewrite URLs when using the shared login domain

https://gerrit.wikimedia.org/r/1071268

Change #1072627 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Rewrite URLs to mobile when using mobile view on shared login domain

https://gerrit.wikimedia.org/r/1072627

r1071268 has this code comment

Only allow links to auth-related special pages on the SSO domain.
Point all other links to the normal wiki domain.

However, most of the sidebar links do not work currently (they link to the auth domain).

https://auth.wikimedia.org/enwiki/wiki/Special:UserLogin?useskin=vector (Vector shows the links more prominently).