Right now temporary passwords are handled by MediaWiki core, not the central login extension, which has various disadvantages (e.g. throttling is per-wiki and easy to get around; the temp password only works on the wiki where you got it; T149003: TemporaryPasswordPrimaryAuthenticationProvider does not work with non-DB-based passwords). CentralAuth should probably duplicate the temp password handling logic and store the data in the central DB.
Description
Description
Details
Details
Related Changes in Gerrit:
Customize query in gerrit
| 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 | None | T14884 Login and account creation should be by secure http. | |||
| Invalid | None | T11816 Improve security for Special:Userlogin (tracking) | |||
| Resolved | matmarex | T19487 mail password per user rate limit should be global for SUL accounts | |||
| Resolved | Tgr | T384219 SUL3 Phase 4: Staged rollout for all existing users | |||
| Open | Tgr | T362715 Move credentials change to central domain | |||
| Resolved | matmarex | T42050 Allow password reset requests to be handled centrally for unified users | |||
| Resolved | matmarex | T151012 CentralAuth should have its own temporary password handling |
Event Timeline
Comment Actions
Change #1057315 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@master] Allow password reset requests to be handled centrally
Comment Actions
Change #1069710 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/core@master] Allow extensions to send password resets without a local user/email
Comment Actions
Change #1069710 merged by jenkins-bot:
[mediawiki/core@master] Allow extensions to send password resets without a local user/email
Comment Actions
Change #1057315 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Allow password reset requests to be handled centrally
Comment Actions
Based on before/after on Beta Cluster, given an account with requireemail enabled in global preference, and the account existing on enwiki, and nlwiki but not dewiktionary, and me having reset password various ways in the hours before merging this patch:
- The temp passwords I got emailed don't work post-merge. This makes sense if the CA class replaces the core one. But, these are normally valid for 7 days. Do we have a strategy for this? Or should we let it break and hope users will try again (despite the the bold text telling them they can only do this once per 24h, while our patch effectivel revokes the tmp password, it also creates a new rate limit).
- Before the merge, pw forget did not seem to work on wikis where my account wasn't auto-created yet (in my case dewiktionary). I thought it would work but not enforce the global pref, but a local account existence check seems to prevent that already. This makes sense, but suggests that this was not bypassable in prod (unless it was a fluke with beta not delivering the email, or me miscounting the rate limit).
- Before the merge, temp passwords are of course specific to each wiki.
- After the merge, pw forget works from all wikis, including those were I don't exist. I used the resulting temp pass emailed to me on another wiki, which also worked nicely.
Comment Actions
The temp passwords I got emailed don't work post-merge. This makes sense if the CA class replaces the core one. But, these are normally valid for 7 days. Do we have a strategy for this? Or should we let it break and hope users will try again (despite the the bold text telling them they can only do this once per 24h, while our patch effectivel revokes the tmp password, it also creates a new rate limit).
Yes, that's expected, but it's a good point that this experience during the rollout is poor. I think this can be fixed by just disabling the AuthManagerFilterProviders hook handler temporarily (here) – this will allow the core class to handle the previously created temp passwords, while the CA class will take priority for newly created ones (because of this). We will want to re-enable this later, so that we don't store extra temporary passwords that the user isn't aware of in the local table. I'll double-check this and send a patch shortly.
Before the merge, pw forget did not seem to work on wikis where my account wasn't auto-created yet (in my case dewiktionary). I thought it would work but not enforce the global pref, but a local account existence check seems to prevent that already. This makes sense, but suggests that this was not bypassable in prod (unless it was a fluke with beta not delivering the email, or me miscounting the rate limit).
Yes, that's also expected, password reset did not work on wikis where you didn't have a local account (see parent task: T42050). Now it works, and that's why we had to make the changes to global pref handling, to allow that preference to be checked on those wikis, previously it was not necessary.
Comment Actions
Change #1075045 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@master] Temporarily allow core password reset functionality
Comment Actions
Change #1075045 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Temporarily allow core password reset functionality
Comment Actions
Change #1075182 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@wmf/1.43.0-wmf.24] Temporarily allow core password reset functionality
Comment Actions
Change #1075182 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@wmf/1.43.0-wmf.24] Temporarily allow core password reset functionality
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2024-09-24T13:35:54Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1075182|Temporarily allow core password reset functionality (T151012)]]
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2024-09-24T13:41:06Z] <lucaswerkmeister-wmde@deploy1003> lucaswerkmeister-wmde, matmarex: Backport for [[gerrit:1075182|Temporarily allow core password reset functionality (T151012)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Comment Actions
Mentioned in SAL (#wikimedia-operations) [2024-09-24T13:46:15Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1075182|Temporarily allow core password reset functionality (T151012)]] (duration: 10m 21s)
Comment Actions
With this temporary fix being backported to wmf.24, we could merge the revert now, so that it will be deployed next week with wmf.25.
Comment Actions
Change #1075248 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):
[mediawiki/extensions/CentralAuth@master] Revert "Temporarily allow core password reset functionality"
Comment Actions
Change #1075248 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] Revert "Temporarily allow core password reset functionality"