Change Details

(NOTE) This is a brainstorming-stage proposal. Don't take it too seriously yet. For Wikimedia's central login system (SUL), we want to have a a single domain for storing a central session cookie that other domains (wikis) can rely on for authentication; and we want to do interactive login on that domain ({T348388} - because browsers increasingly require user interaction with the cookie-storing domain before giving access to cookies); but we want the interaction on that domain to be similar to the interaction on the wiki where the user is logging in (in terms of i18n customizations, AbuseFilter/SpamBlacklist username rules etc). One way to do this would be for the central login wiki's login page to fetch the relevant information from the origin wiki in a bunch of API calls and customize itself accordingly. This seems like a lot of effort with a long tail of small inconsistencies that will take forever to squash. An alternative approach would be to use a new domain, say `https://sso.wikimedia.org/<wikiID>/`, which would to resolve to the wiki specified in `<wikiID>` (ie. this page would be served by the same wiki from which the user started the login process, but under a different domain). We would limit what URLs can be accessed on this new domain, and add a bunch of config/hook overrides, like limiting what pages can be viewed and limiting user rights to only those needed for login, and maybe splitting some caches. This would hugely simplify how displaying the central login page would work, although it would complicate the configuration system. I think (although I am not very sure) it would be a simpler approach on the net.

(NOTE) This is a brainstorming-stage proposal. Don't take it too seriously yet. For Wikimedia's central login system (SUL), we want to have a a single domain for storing a central session cookie that other domains (wikis) can rely on for authentication; and we want to do interactive login on that domain ({T348388} - because browsers increasingly require user interaction with the cookie-storing domain before giving access to cookies); but we want the interaction on that domain to be similar to the interaction on the wiki where the user is logging in (in terms of i18n customizations, AbuseFilter/SpamBlacklist username rules etc). One way to do this would be for the central login wiki's login page to fetch the relevant information from the origin wiki in a bunch of API calls and customize itself accordingly. This seems like a lot of effort with a long tail of small inconsistencies that will take forever to squash. An alternative approach would be to use a new domain, say `https://sso.wikimedia.org/<wikiID>/`, which would to resolve to the wiki specified in `<wikiID>` (ie. this page would be served by the same wiki from which the user started the login process, but under a different domain). We would limit what URLs can be accessed on this new domain, and add a bunch of config/hook overrides, like limiting what pages can be viewed and limiting user rights to only those needed for login, and maybe splitting some caches. This would hugely simplify how displaying the central login page would work, although it would complicate the configuration system. I think (although I am not very sure) it would be a simpler approach on the net. It would also be a mixed change in terms of security - the login domain would be very much locked down compared to login.wikimedia.org (a real wiki), which is good, but it could be served by any wiki, ie. any backend code deployed in the Wikimedia cluster could potentially run on it, which is bad.

(NOTE) This is a brainstorming-stage proposal. Don't take it too seriously yet. For Wikimedia's central login system (SUL), we want to have a a single domain for storing a central session cookie that other domains (wikis) can rely on for authentication; and we want to do interactive login on that domain ({T348388} - because browsers increasingly require user interaction with the cookie-storing domain before giving access to cookies); but we want the interaction on that domain to be similar to the interaction on the wiki where the user is logging in (in terms of i18n customizations, AbuseFilter/SpamBlacklist username rules etc). One way to do this would be for the central login wiki's login page to fetch the relevant information from the origin wiki in a bunch of API calls and customize itself accordingly. This seems like a lot of effort with a long tail of small inconsistencies that will take forever to squash. An alternative approach would be to use a new domain, say `https://sso.wikimedia.org/<wikiID>/`, which would to resolve to the wiki specified in `<wikiID>` (ie. this page would be served by the same wiki from which the user started the login process, but under a different domain). We would limit what URLs can be accessed on this new domain, and add a bunch of config/hook overrides, like limiting what pages can be viewed and limiting user rights to only those needed for login, and maybe splitting some caches. This would hugely simplify how displaying the central login page would work, although it would complicate the configuration system. I think (although I am not very sure) it would be a simpler approach on the net. It would also be a mixed change in terms of security - the login domain would be very much locked down compared to login.wikimedia.org (a real wiki), which is good, but it could be served by any wiki, ie. any backend code deployed in the Wikimedia cluster could potentially run on it, which is bad.