[06:27:45] bd808: how would a non-dinosaur tech look? if the user visits domain X but they have previously authenticated on domain Y, there isn't really a way to seamlessly log them in without relying on crossdomain cookies. [06:30:21] (Unless you use a shared second-level domain for everything and put the cookie there, which is bad for security, or do cross-domain redirects instead of cross-domain cookies, which only works for GET requests, results in terrible UX when something goes wrong, and I don't think it can preserve the URL fragment.) [09:01:35] tgr: cookie sharing applies to subresources and fetches, not top level navigation. So auto-login won't be possible but one-click login certainly is [09:01:45] sharding* [09:02:19] By performing a redirect via login wiki that uses query params to communicate relevant IDs [09:03:16] Basically the same way you login to random websites that use Google/mediawiki/Twitter/OpenID etc if you've already authenticated before but haven't used the random site in a while [09:03:26] You click login and then immediately are logged in [09:07:23] There's also work on a new browser API to make this work without a click possibly: https://developer.chrome.com/docs/privacy-sandbox/fedcm/ [09:07:36] And chrome likely won't launch the last phase of their privacy sandbox without it [09:08:38] There's also https://developer.chrome.com/docs/privacy-sandbox/first-party-sets/ which is said to be recommended for cases where you own both sites [09:11:33] When do we need a cross domain POST to perform auto-login? Afaik that could only happen for API requests in which case CA tokens remove the need for a local cookie-based session [15:54:24] tgr_: as far as I understand the use case, this is what OpenID Connect (OIDC) was designed to handle in 2014. https://infosec.mozilla.org/guidelines/iam/openid_connect.html [15:56:46] There are fancy iframe tricks that can be played to get cross-domain data sharing working without cross-domain cookies if that is truly needed. Having the act of clicking the login link do a redirect to the IdP is a less complex approach. [15:57:47] There would probably be something that we like about our prior system that would be lost, but if we could get anything functional back now that the prior system is non-functional then that feels like a win. [17:28:19] bd808: OIDC will also use cookies because how else would the identity provider store state. Data sharing is not the issue; as Krinkle says, browsers usually tie session access to being in a top-level navigation context, which makes a seamless login check hard (if at all possible). First-party sets would be the web standard proposal for solving this, but I don't think it's moving much. [17:30:20] Which is not to say there wouldn't be plenty of benefits from using a standard, widely understood authn/authz protocol. But the way it interacts with the browser isn't fundamentally different. [17:31:29] The minimal-effort fix would probably be to kick off a top-level redirect-based autologin sequence when the user opens the login page and does not have the failed central login localstorage flag set. [17:34:51] IIRC Firefox has a hardcoded internal equivalent of first-party sets and TimStarling tried to get us added there, not sure what came out of that. [17:35:43] https://bugzilla.mozilla.org/show_bug.cgi?id=1696095 [17:35:44] still open [17:40:45] "When do we need a cross domain..." <- Session expiry during form submit, I suppose, if you are thinking about in the context of a seamless login via top-level redirect. But the bigger problem, I think, is that you cannot preserve section IDs and such. Plus if anything breaks you end up on an error page on loginwiki which is very confusing (to be fair, it already happens if something breaks during login). [18:40:53] https://www.thearmchaircritic.org/mansplainings/reauthenticating-a-user-without-redirection-in-oidc talks about one of the fancy iframe tricks which is using https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage to carry data from the IdP to javascript running in the foregrounded RP. I don't think this is actually a lot different than what I understand the current cross-domain cookie design to be _except_ it adds an iframed page [18:40:53] load to check the IdP side auth state. [18:47:17] I think I would be personally happy with a solution that matches what tgr_ called minimal-effort, when I hit the login link then redirect to loginwiki and redirect back when auth is done. [19:16:04] I think the iframe-based approach would be affected by cross-browser limitations the same way our AJAX-based and pixel-based techniques are. [19:19:53] tgr_: ack, I wasn't thinknig of redirecting all pageviews without a CA Anon cookie to loginwiki to try and autologin. I meant specifically on-click when you need a login. I interpreted your corss-domain use case as e.g. enwiki to commonswiki where commonswiki might be logged-out. [19:25:00] We have three cross-domain flows currently: local -> loginwiki via AJAX when checking whether the user is logged in, local -> loginwiki -> local via via top-level redirect when the user just logged in and we want to log them in on loginwiki, and local -> some other wiki -> loginwiki -> the other wiki via image when the user just logged in and we want to preemptively log them in on every second-level domain. [19:26:21] (Plus we set a cookie on the local second-level domain on login, which isn't a cross-domain operation from the browser's POV, but does help with domain jumping within the same project.) [19:28:37] In theory it is the third one which provides a seamless login experience on all major domains, and the first one is a somewhat sketchy fallback (it logs you in in the background and then replaces the user toolbar, so you end up logged in with a mostly-logged-out skin but your personal toolbar links). [19:30:29] Cross-domain API requests can use centralauthtoken but it's not convenient (you need a new token for every request, so basically you are doubling the number of API calls). That's one place where OIDC would definitely be an improvement. [19:31:42] Or not so much OIDC specifically as some kind of built-in OAuth, I suppose. [20:45:08] > I think the iframe-based approach would be affected by cross-browser limitations -- the postMessage API was added very specifically to allow two actively collaborating sites to break out of the same-origin policy. I used it to good effect at $DAYJOB-1 for passing advice on device reputation from our PaaS to the checkout pages at embedding merchants. [20:46:07] postMessage is circa 2010 tech so likely to be in all of the human driven user-agents that can also meet our TLS support requirements. [23:25:41] three CR+1's on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/862401 , does that add up to CR+3? [23:29:06] there's a high five joke in there now [23:31:55] excellent, thanks Reedy