Currently when logging in to multiple wikis via central login / autologin, all wikis will end up with the same central session (they will have the same centralauth_Session cookie value, and so the CentralAuth session provider will fetch the same data hash in the central session store when verifying a request). With the current implementation of SUL3, this is not the case - the local wiki and the shared login domain will end up with different central session IDs.

I'm not sure if this has any effect in practice (we don't store random data in the central session like we do in the local one, and logout relies on the central user token). Still, it would be nice to fix.

Central login and autologin send the central session ID via the token store and then set it manually (via the $reset argument of CentralAuthSessionManager::setCentralSession()). In SUL3, we can send the ID the same way but (as opposed to central login / autologin which do it manually) the local session will be updated by AuthManager, so it's less obvious where and how to inject the session ID:

• We can do it after login (e.g. in the postAuthentication() auth provider callback), but by then a new central session has already been created and so that will be left behind. (Not a big deal, but again, nicer if we don't do it.)
• We can store the central session ID as soon as we receive it (before the user actually gets logged in), as it's stored in the local session as normal data, and we can do that even for unattached sessions, but then we'd have to be really sure that won't go wrong somehow if another login provider interrupts login and the user does not get logged in, and then the local session is reused.
• We could add a new hook point (eww).
• We could delay saving the session until postAuthentication() has run so one can freely mess with it (this came up for T369668: Figure out how to handle "remember me" flag in SUL3 login flow but in the end we chose a different approach). That would probably make the system a little less robust (an error in one of the callbacks would mean session cookies don't get written), although amost nothing uses post-authentication callbacks so realistically it wouldn't matter much.