The shared login domain proposed in T363695: Create a Wikimedia login domain that can be served by any wiki does not have a mobile variant, and the domain in the URL path doesn't use it either (so e.g. a user starting login at https://en.m.wikipedia.org/ will be redirected to https://sso.wikimedia.org/en.wikipedia.org/...) but we do need to preserve the fact that the user arrived from a mobile domain, so we can send the user back there after authentication, and so we can point the various links (terms of use etc.) there. We hope to avoid having separate mobile and desktop versions of the login page itself, but eventually needing that isn't completely out of the question either. And we probably need to have some concept of "mobile site" and "desktop site" for analytics, even if its actually the same site, because it is commonly used in our metrics as a proxy for the user using a mobile device.
There are a couple ways to do this:
- Do set up a separate mobile domain (sso.m.wikimedia.org vs. sso.wikimedia.org). This is straightforward but has lots of negative consequences (splits mobile and desktop login state, splits password manager entries, makes it hard to use WebAuthn etc) so if possible we should avoid it. (login.wikimedia.org also does not have a mobile variant, to avoid splitting the login state.)
- Use the mobile domain in the URL when indicating where the user came from (ie. https://sso.wikimedia.org/en.m.wikipedia.org/... instead of https://sso.wikimedia.org/en.wikipedia.org/...). That we don't do this already is somewhat of an accident of how mobile domain handling works (the path is generated from $wgServer which does not reflect whether we are on the mobile domain). But the implementation would probably be quite messy:
- The URL is set up in operations/mediawiki-config, so too early to directly use things like MobileContext, and we'd have to duplicate the relevant logic.
- MobileContext::usingMobileDomain() is based on a header set in Varnish; we'd either have to fake that, or add some kind of hook mechanism.
- Even on normal domains, MobileFrontend is not very reliable or predictable at mobilifying URLs.
- Create a custom mechanism where e.g. login redirects coming from mobile domains include frommobile=1 and that gets passed around and acted upon. This is what Special:CentralLogin/CentralAutoLogin do today, but not great for maintainability.
- Integrate the concept of domain variants better with MediaWiki core (T195494: Handle mobile domains in core). This would be challenging in terms of change management.