Seen on a local setup, where after a successful SUL3 login the local wiki deleted the CentralAuth cookies and replaced them with an anonymous local session. Not 100% sure this was the issue but seems likely.
(Not an issue in Wikimedia production where the central domain doesn't share a parent domain with anything else.)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T345245 Mitigate phase-out of third-party cookies in Wikimedia production | |||
| Resolved | Tgr | T345249 Mitigate phase-out of third-party cookies in CentralAuth | |||
| Open | None | T348388 SUL3: Use a dedicated domain for login and account creation | |||
| Resolved | JTweed-WMF | T375954 Create SUL3 rollout plan for Wikimedia production | |||
| Resolved | Tgr | T377258 Write mediawiki.org documentation for SUL3 | |||
| Declined | None | T391358 SUL3 login broken when the local wiki and the central domain are in the same $wgCentralAuthCookieDomain set |
Setting $wgCentralAuthCookiePrefix in your MW config for the shared domain would probably work around that. Maybe we should recommend doing that.
Good point, that might be the easiest way of fixing it.
It would be nice to understand why it's happening (maybe some combination of T372703: Set central session ID on the local wiki during SUL3 login and session store lag?), not the most important thing though.
I mentioned this caveat in the docs I wrote at https://www.mediawiki.org/wiki/Extension:CentralAuth#SUL3. I think we can say that this is a configuration error and not a bug.