Page MenuHomePhabricator

Move credentials change to central domain
Closed, ResolvedPublic

Description

As part of T348388: SUL3: Use a dedicated domain for login and account creation, the login and signup forms would be moved to the central login wiki. It would make sense to move the credentials change forms (password change, 2FA change) as well. This doesn't block rollout of the other SUL3 work, and could be done much later, apart from WebAuthn where we'd have to disable the local form at least (T354701: Enable migration of WebAuthn credentials to central domain).

In the simplest form, this could just mean changing the various Special:Preferences buttons to be simple links, and adding returnto support to credentials change pages (the various AuthManagerSpecialPage subpages + OATH/WebAuthn).

Details

Related Changes in Gerrit:
SubjectRepoBranchLines +/-
mediawiki/extensions/CentralAuthmaster+0 -42
mediawiki/extensions/WikimediaMessagesmaster+0 -8
mediawiki/extensions/CentralAuthmaster+42 -0
mediawiki/extensions/WikimediaMessagesmaster+7 -0
mediawiki/extensions/CentralAuthmaster+167 -0
mediawiki/extensions/CentralAuthmaster+7 -6
mediawiki/extensions/CentralAuthmaster+1 -0
mediawiki/extensions/CentralAuthmaster+57 -6
mediawiki/extensions/CentralAuthwmf/1.44.0-wmf.21+57 -6
mediawiki/extensions/CentralAuthwmf/1.44.0-wmf.21+1 -0
mediawiki/extensions/CentralAuthwmf/1.44.0-wmf.21+7 -6
mediawiki/extensions/CentralAuthmaster+30 -2
mediawiki/coremaster+31 -16
mediawiki/extensions/CentralAuthwmf/1.44.0-wmf.20+7 -2
mediawiki/extensions/CentralAuthmaster+7 -2
Show related patches Customize query in gerrit

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change #1125166 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/core@master] specials: Adapt SpecialChangeCredentials to redirect flow

https://gerrit.wikimedia.org/r/1125166

Change #1125168 had a related patch set uploaded (by D3r1ck01; author: Derick Alangi):

[mediawiki/extensions/CentralAuth@master] Move Special:ChangeCredentials to shared domain

https://gerrit.wikimedia.org/r/1125168

Change #1127682 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Enable credentials change special pages on SUL3 shared domain

https://gerrit.wikimedia.org/r/1127682

I feel like maybe we should redirect to the shared domain in onSpecialPageBeforeExecute for these special pages or something. It seems weird to allow them to be accessed in both ways.

We need to keep the old URLs working for disabling WebAuthn, at a minimum. But in the long term, yeah, there should be exactly one domain where they are accessible.

Change #1127682 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Enable credentials change special pages on SUL3 shared domain

https://gerrit.wikimedia.org/r/1127682

Change #1127965 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.20] Enable credentials change special pages on SUL3 shared domain

https://gerrit.wikimedia.org/r/1127965

One tricky aspect here is that after credentials change we reset the session ID and invalidate all other sessions, for security reasons (the idea being that often people change passwords because they think their account has been compromised, and then we don't want the attacker's account to continue working). That means that the user will stay logged in on the domain where the credentials change happens, but will get logged out in the home domain. We could just do a top-level autologin to log them in again, but it isn't obvious when and how to intercept the control flow to do that.

It mostly works out in practice though because usually people get to credentials change from Special:Preferences, and Special:Preferences will redirect to login (and eventually do a top-level autologin) when the returning user is not logged in.

OATHAuth/WebAuthn always just returns to its manage form after a change so there it's more disruptive.

Change #1128044 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Redirect credentials change pages to central domain

https://gerrit.wikimedia.org/r/1128044

OATHAuth/WebAuthn always just returns to its manage form after a change so there it's more disruptive.

I guess we could schedule an edge login in SessionProvider::sessionIdWasReset(). We'd have to go back on rECAU8b7bb772f9ba: Do not trigger edge login on the shared domain then (but there wasn't a strong rationale for it so that's fine).

Change #1127965 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.20] Enable credentials change special pages on SUL3 shared domain

https://gerrit.wikimedia.org/r/1127965

Mentioned in SAL (#wikimedia-operations) [2025-03-17T13:23:01Z] <tgr@deploy2002> Started scap sync-world: Backport for [[gerrit:1127965|Enable credentials change special pages on SUL3 shared domain (T362715)]]

Mentioned in SAL (#wikimedia-operations) [2025-03-17T13:27:33Z] <tgr@deploy2002> tgr: Backport for [[gerrit:1127965|Enable credentials change special pages on SUL3 shared domain (T362715)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-03-17T13:48:44Z] <tgr@deploy2002> Finished scap sync-world: Backport for [[gerrit:1127965|Enable credentials change special pages on SUL3 shared domain (T362715)]] (duration: 25m 42s)

Change #1125166 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] specials: Adapt SpecialChangeCredentials to redirect flow

Reason:

Superseded by https://gerrit.wikimedia.org/r/1128044

https://gerrit.wikimedia.org/r/1125166

Change #1125168 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/CentralAuth@master] Move Special:ChangeCredentials to shared domain

Reason:

Superseded by https://gerrit.wikimedia.org/r/1128044

https://gerrit.wikimedia.org/r/1125168

Change #1128044 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Redirect credentials change pages to central domain

https://gerrit.wikimedia.org/r/1128044

Change #1130319 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Redirect credentials change pages to central domain

https://gerrit.wikimedia.org/r/1130319

Change #1130526 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Do not throw an exception after shared-domain login with no token

https://gerrit.wikimedia.org/r/1130526

Change #1130528 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Do not start central login from the shared domain

https://gerrit.wikimedia.org/r/1130528

Change #1130528 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Do not start central login from the shared domain

https://gerrit.wikimedia.org/r/1130528

Change #1130526 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Do not throw an exception after shared-domain login with no token

https://gerrit.wikimedia.org/r/1130526

Change #1130560 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Do not throw an exception after shared-domain login with no token

https://gerrit.wikimedia.org/r/1130560

Change #1130561 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Do not start central login from the shared domain

https://gerrit.wikimedia.org/r/1130561

Change #1130560 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Do not throw an exception after shared-domain login with no token

https://gerrit.wikimedia.org/r/1130560

Change #1130561 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Do not start central login from the shared domain

https://gerrit.wikimedia.org/r/1130561

Mentioned in SAL (#wikimedia-operations) [2025-03-24T13:33:27Z] <tgr@deploy1003> Started scap sync-world: Backport for [[gerrit:1130343|Turn on Parsoid fragment support everywhere (take 2) (T374661 T380758 T389545 T387608)]], [[gerrit:1130560|Do not throw an exception after shared-domain login with no token (T362715)]], [[gerrit:1130561|Do not start central login from the shared domain (T362715)]]

Mentioned in SAL (#wikimedia-operations) [2025-03-24T13:37:04Z] <tgr@deploy1003> tgr, cscott: Backport for [[gerrit:1130343|Turn on Parsoid fragment support everywhere (take 2) (T374661 T380758 T389545 T387608)]], [[gerrit:1130560|Do not throw an exception after shared-domain login with no token (T362715)]], [[gerrit:1130561|Do not start central login from the shared domain (T362715)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-03-24T13:54:09Z] <tgr@deploy1003> Finished scap sync-world: Backport for [[gerrit:1130343|Turn on Parsoid fragment support everywhere (take 2) (T374661 T380758 T389545 T387608)]], [[gerrit:1130560|Do not throw an exception after shared-domain login with no token (T362715)]], [[gerrit:1130561|Do not start central login from the shared domain (T362715)]] (duration: 20m 42s)

Change #1130319 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@wmf/1.44.0-wmf.21] Redirect credentials change pages to central domain

https://gerrit.wikimedia.org/r/1130319

Mentioned in SAL (#wikimedia-operations) [2025-03-24T14:31:52Z] <tgr@deploy1003> Started scap sync-world: Backport for [[gerrit:1130319|Redirect credentials change pages to central domain (T362715)]], [[gerrit:1130607|Fix clearing stuck cookies: $wgCookiePrefix defaults to false, not null (T389796)]]

Mentioned in SAL (#wikimedia-operations) [2025-03-24T14:36:49Z] <tgr@deploy1003> matmarex, tgr: Backport for [[gerrit:1130319|Redirect credentials change pages to central domain (T362715)]], [[gerrit:1130607|Fix clearing stuck cookies: $wgCookiePrefix defaults to false, not null (T389796)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-03-24T14:51:31Z] <tgr@deploy1003> Finished scap sync-world: Backport for [[gerrit:1130319|Redirect credentials change pages to central domain (T362715)]], [[gerrit:1130607|Fix clearing stuck cookies: $wgCookiePrefix defaults to false, not null (T389796)]] (duration: 19m 38s)

matmarex renamed this task from Move credentials change to central login wiki to Move credentials change to central domain.Apr 8 2025, 6:55 PM

What's left here:

  • Make the OATH credentials management special page redirect to the central domain. We can't do this right now because WebAuthn users need to be able to remove old passkeys, and that only works on the same domain where you registered it.
    • For now, we could make the 2FA management button point to the central domain (but let users manually navigate to the local domain).
    • Alternatively, we could use usesul3= like for many other things. But it's tricky because it needs to be preserved over form submits.
      • Maybe we could make the AuthPreserveQueryParams hook more generic and have OATHAuth call it. But it feels like a lot of work for a one-off use case. (Although I guess some kind of redirecting-to-another-domain workflow would make sense for the WebAuthn extension, even when it's not used with CentralAuth?)
    • In any case, we'll probably want to add some explanatory text on the page.
    • Or we can just assess how many WebAuthn keys have been updated (by looking at the date), and if it's almost all of them, just accept that the remaining users are locked out and need to approach T&S. (It was only ~100 passkeys to start with.)
  • Update T263800: Implement .well-known/change-password redirect on Wikimedia sites to use the new URL. This is a bit trickier now because it includes the wiki ID now. If it's difficult, maybe not worth doing at all (the old URL will still redirect).
  • Test what happens after a password change or OATH change in terms of the session ID reset affecting the user's login state on the home wiki. Maybe do an edge login, per T362715#10639947.

Change #1135091 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/WikimediaMessages@master] Remove WebAuthn message overrides

https://gerrit.wikimedia.org/r/1135091

Change #1136096 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Hide sitenotices on the central domain and show WebAuthn notice

https://gerrit.wikimedia.org/r/1136096

Change #1136097 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/WikimediaMessages@master] Override for CentralAuth SUL3 notice about WebAuthn domains

https://gerrit.wikimedia.org/r/1136097

Change #1136096 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Hide sitenotices on the central domain and show WebAuthn notice

https://gerrit.wikimedia.org/r/1136096

Change #1136097 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Override for CentralAuth SUL3 notice about WebAuthn domains

https://gerrit.wikimedia.org/r/1136097

Change #1138741 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/CentralAuth@master] Make central domain the default for Special:OATHManage

https://gerrit.wikimedia.org/r/1138741

Change #1138741 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Make central domain the default for Special:OATHManage

https://gerrit.wikimedia.org/r/1138741

Change #1135091 abandoned by Bartosz Dziewoński:

[mediawiki/extensions/WikimediaMessages@master] Remove WebAuthn message overrides

Reason:

Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/1174101

https://gerrit.wikimedia.org/r/1135091

What's left here:

  • Make the OATH credentials management special page redirect to the central domain. We can't do this right now because WebAuthn users need to be able to remove old passkeys, and that only works on the same domain where you registered it.

This is T401773

What's left here:

  • Make the OATH credentials management special page redirect to the central domain. We can't do this right now because WebAuthn users need to be able to remove old passkeys, and that only works on the same domain where you registered it.

Would users still be able to log in with those old passkeys? (Or, in general, are those users able to log in or reauthenticate?) If so, I think we could resolve this issue a different way. Now that T402094 is done, we are planning to no longer require a special authentication step when removing an authenticator. Instead, we can just rely on the special page forcing reauth. This is important because we want users who have multiple 2FA methods and have lost one of them to be able to remove one method by authenticating with the other method.

All that is to say, if we make this change, I believe we could redirect the OATHManage special page to the central domain without breaking users' ability to remove local-only WebAuthn keys, as long as they are able to log in somehow.

For now, we could make the 2FA management button point to the central domain (but let users manually navigate to the local domain).

Was done in (rECAU0ad3edb70420: Make central domain the default for Special:OATHManage).

In any case, we'll probably want to add some explanatory text on the page.

Was done in (rECAUb3abf365064e: Hide sitenotices on the central domain and show WebAuthn notice / rEWME5e756ca0097c: Override for CentralAuth SUL3 notice about WebAuthn domains).

Or we can just assess how many WebAuthn keys have been updated (by looking at the date), and if it's almost all of them, just accept that the remaining users are locked out and need to approach T&S. (It was only ~100 passkeys to start with.)

See the parent task.

Update T263800: Implement .well-known/change-password redirect on Wikimedia sites to use the new URL. This is a bit trickier now because it includes the wiki ID now. If it's difficult, maybe not worth doing at all (the old URL will still redirect).

Let's not do it. The redirects are generated in mediawiki::web::vhost in puppet, which doesn't have a concept of the wiki ID and it would be pretty hard to add (as usually the same Apache ruleset is used for the entire second-level domain). Password change via .well-known is a fringe workflow, one extra redirect won't hurt.

Test what happens after a password change or OATH change in terms of the session ID reset affecting the user's login state on the home wiki. Maybe do an edge login, per T362715#10639947.

This works fine. When the user submits Special:ChangePassword on the central domain, the user token is updated (so all existing sessions are invalidated); the user immediately receives a new session on that domain via Session::resetId() (so the central session remains valid and autologin will keep working); they then return to the local domain where the session is now invalid, get sent to do a top-level central autologin (courtesy of being returned to Special:Preferences which requires login, so it sends the user to the local login page, which does the top-level central autologin) and that gives them a new, valid session.

If auth.wikimedia.org/.../Special:ChangePassword were to redirect the user back to a local page which doesn't require login (possible, since it honors returnto query parameters), the user would get logged out locally (and then depending on the browser probably do an AJAX autologin and be logged in on the next request). Seems too fringe a scenario to worry about.

Would users still be able to log in with those old passkeys? (Or, in general, are those users able to log in or reauthenticate?)

On the old login domains yes, on the new one, no. We sent them some emails about it (T389064) but people who don't read that are now effectively locked out since the login UI doesn't give you any hint on how to do that. And we want to remove the possibility soonish (T402423).

Now that T402094 is done, we are planning to no longer require a special authentication step when removing an authenticator. Instead, we can just rely on the special page forcing reauth. This is important because we want users who have multiple 2FA methods and have lost one of them to be able to remove one method by authenticating with the other method.

Reauthentication also happens on the central domain, so even if these users have a valid login session (logins can be valid for up to one year), they won't be able to make changes to their passkeys.
(You can do a login or reauthentication on the local domain, for now, but it requires manually messing with the URLs.)

It's a tiny number of users so it might be fine to just lock them out and have them go to T&S, or forcibly remove their passkeys or something like that. @EMill-WMF will decide that based on T401742.

@EMill-WMF will decide that based on T401742.

Just to be clear @Tgr, there's still work to be done in T401742 on this, right? That's how I'm reading the current thread there. If it's now waiting on me, please let me know.

Yeah, I meant you'll decide once that task is done.

Change #1195269 had a related patch set uploaded (by Krinkle; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Remove preferences override to link to central domain for Special:OATHManage

https://gerrit.wikimedia.org/r/1195269

Change #1195269 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Remove preferences override to link to central domain for Special:OATHManage

https://gerrit.wikimedia.org/r/1195269

The last step (removing the ability to visit the 2FA management on the local domain without using usesul3=0) was done a while ago (T401773: Always redirect 2FA management special page to auth domain on SUL wikis, so that WebAuthn setup can be offered).

Removing usesul3 support (and with it the last chance to use WebAuthn on the local domain) is tracked in T402423: Remove &usesul3= URL parameter.