Currently when using CentralAuth with a central login wiki, login or signup still happens locally (the "central login wiki" is really more of a central session wiki), so hooks mostly fire the same way they would on baseline MediaWiki. After T348388: Use central login wiki for login (SUL3) this won't necessarily be the case, so we need to adjust how this hooks are invoked, or update the logic of callers of these hook which are expected to be used together with CentralAuth (and maybe provide alternatives like CentralAuth currently does for PostLoginRedirect).
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T345245 Mitigate phase-out of third-party cookies across MediaWiki in production | |||
| Open | None | T345249 Mitigate phase-out of third-party cookies in CentralAuth | |||
| Open | None | T348388 Use central login wiki for login (SUL3) | |||
| Open | None | T362713 Implement the new login process which redirects to the central login wiki for showing the login/signup form | |||
| Stalled | None | T364866 Adapt to changes in post-login/signup hooks after switching to a central login wiki |
Event Timeline
Comment Actions
This is a first guess but we'll have to audit hook usage:
- Hooks that do or display things after a successful login (UserLoginComplete, PostLoginRedirect / CentralAuthPostLoginRedirect, LocalUserCreated with autocreate=true; also not-quite-hook callbacks like the postAuthentication callback of an AuthManager authentication provider) should keep working since the the local wiki still sees central login / signup as a login event. We might need to make sure that (some of) these hooks do not run on the central login wiki, though. (And in popup mode, we might want to provide their return values via a Javascript callback so the UI that initiated async login / signup can decide how to handle it, instead of trying to display them in the popup - this is handled in T364939: Provide a JavaScript library for logging in / signing up to MediaWiki via a popup.)
- Hooks that do or display things after a successful signup (BeforeWelcomeCreation, LocalUserCreated with autocreate=false; also not-quite-hook callbacks like the finishAccountCreation callback of an AuthManager authentication provider) will not run locally, since the local wiki will only see an autocreation (the actual account creation will happen on the central login wiki). Especially for LocalUserCreated, this will probably disrupt a lot of assumptions in current code. We might want a CentralUserCreated or similar hook that runs in the wiki which initiated the account creation.
- Hooks that run during authentication and have no visible output (AuthManagerLoginAuthenticateAudit, ExemptFromAccountCreationThrottle) will run on the central login wiki instead of the local wiki, but this probably won't make any difference.
- SpecialCreateAccountBenefits will run on the central wiki, which means both that it needs access to the starting wiki (currently it just assumes that's the wiki it's running on), and that allowing customization via on-wiki i18n messages, community configuration etc. is nontrivial.
- LoginFormValidErrorMessages is used by extensions to add their own error messages, that might be tricky if the extension is not installed on the central login wiki.
Logout and temp user creation (UserLogout, UserLogoutComplete, TempUserCreatedRedirect) are not affected by the changes.
Comment Actions
Hopefully we can avoid this entire problem cluster via T363695: Create a Wikimedia login domain that can be served by any wiki.