In vanilla MediaWiki, this would only be a minor inconvenience (you'd have to log out before logging in as another user). In CentralAuth, logout affects all your domains and devices, so people might intentionally want to switch accounts without logging out. (I'm not super sure it's a good idea to support that; it's easy to end up logged in as a different user on different domains after that. But we changed it by accident, so we should either fix that or declare it intentional.)

I was able to reproduce the /wiki/Special:UserLogin?usesul3=1 part (which doesn't present the login form but just re-triggers a login chain) but couldn't reproduce /wiki/Special:UserLogin?usesul3=0. The later will present to me a login form that I can use locally to authenticate as a different user.

Can you confirm that my observation with usesul3=0 flag is accurate? My local experience matches my experience on testwiki (the link you shared in the task description).

In SUL2 mode, you see the login page with a notice saying something like "You are already logged in as Foo. Use the form below to log in as another user." In SUL3 mode, you just end up on the main page (because CentralAuthRedirectingPrimaryAuthenticationProvider actually attempts a login, I suspect).

I tagged this with CentralAuth but it might actually be a core issue - normally in LoginSignupSpecialPage::execute(), trySubmit() returns false when the request is GET, execute() returns early, and the login form is rendered but not submitted, but then LoginSignupSpecialPage::canBypassForm() is true, we always submit.

I think we might want something like:

• when the user is already logged in, trySubmit() is always false (so the user will see the local login form, with just a single button)
• when the user is already logged in, the CentralAuthRedirectingAuthenticationRequest button has a different text ("click to log in as another user")
• when the user is already logged in, CentralAuthRedirectingPrimaryAuthenticationProvider somehow ensures that the auth domain form is not skipped (not sure if there's a non-hacky way - normally we'd achieve that by not setting returnto, but then returnto is needed to for the PostLoginRedirect hook to be invoked, so we might need to add an extra redirect somewhere)

or maybe just the last one, showing the button might be pointless.

Alternatively, we might just accept that this now doesn't work, not sure if people actually used it.

One question I have is which login page are we supposed to show to the user in the SUL3 case? I think it's going to be the login form on the shared domain right? Not the local one I assume?

If it's the one on the shared domain, getting there without forwarding the necessary parameters like the login token and the rest would be problematic because if they're absent, the users will be stuck on the shared domain (even though they'll see the login form) and never know where to redirect back to. That's not a great experience (and when they're present, we just assumed logged in and redirect the user back never seeing the login form).

Alternatively, if we try to hack and simulate a local login form (as in SUL2), the system in its current state will show the login form twice - once on the local domain and after filling it and submitting, we'll then show another login form on the shared domain which is not a great experience either.

What I want to try is in the case of SUL3 when a user is already logged in and visits the Special:Userlogin page, we'll just emulate a normal login (even with an active session). This way, we forward all URL query parameters and we will have to play a bit with the special page before execute logic so that it doesn't detect an active session and just redirect back to the local domain.

The normal login form definitely needs to be shown on the central domain, otherwise we'd be going back to SUL2.
Showing the SUL3 local "login form" (which is just a single button, since the other providers are filtered out) might maybe make sense in some situations, but more likely it's pointless friction, and confusing.

In T392359#10758656, @DAlangi_WMF wrote:

What I want to try is in the case of SUL3 when a user is already logged in and visits the Special:Userlogin page, we'll just emulate a normal login (even with an active session). This way, we forward all URL query parameters and we will have to play a bit with the special page before execute logic so that it doesn't detect an active session and just redirect back to the local domain.

Yeah, from the perspective of the local wiki this is just a normal login flow. You can do that while already logged in, and it will just redirect to the auth domain as usual. The tricky part is how to avoid the automatic redirect on the auth domain.

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

[mediawiki/extensions/CentralAuth@master] SUL3: Allow viewing Special:UserLogin while logged in

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

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

[mediawiki/extensions/CentralAuth@master] SUL3: Allow viewing Special:CreateAccount?returnto=… while logged in

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

Change #1187923 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] SUL3: Allow viewing Special:UserLogin while logged in

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

Change #1187924 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] SUL3: Allow viewing Special:CreateAccount?returnto=… while logged in

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