For the record, with <base href> this would work for search (both the /w/rest.php queries, and the /w/index.php GET submission), and possibly other API queries we can expect during auth requests given that these should not need to be restricted by CORS.

I'm aware last time we tried, there were issues with form submission, but that seems much closer in the SUL3 domain where workarounds would be more contained, compare to e.g. ResourceLoader (T371530), API (T380552), and the skin (this task) needing special support.

I'm only mentioning this so that if we re-explore that at some point in the future, we can find it through task references to T371530#10167845. This is not a suggestion. Ignore this comment :)

It looks like we need Ajax support to api.php for T380552: Fix client-side password validity check on SUL3 (Api base URL broken), possibly the fix there could also address rest.php. Although as-is that will indeed not suffice because we overwrite $wgScriptPath in auth-context and thus form submission will still be denied.

I don't see a great way to make that work in a general sense we have contradictory requirement right now. E.g. authentication forms should submit to the auth-domain/enwiki/w/ and other things to canonical-domain/w/. With a base tag, this would work so long as we take care of our own forms.

I agree with @Tgr that as-is, we'd have to either disable this feature or add additional injection support in the skin to change this one form (and hoping there won't be any new ones like it in the future).

In T381096#10365966, @Krinkle wrote:

For the record, with <base href> this would work for search (both the /w/rest.php queries, and the /w/index.php GET submission), and possibly other API queries we can expect during auth requests given that these should not need to be restricted by CORS.

In general we don't want to redirect API requests to the base domain. It's not identical, both because the configuration differs (e.g. most authentication providers are disabled on the base domain), and because the cookies (and so the user session) differ. There are various APIs involved in web-based authentication (username availability check, password strength check, the WebAuthn endpoint), those would all break.

Having some of the API requests go to the base domain and some to the authentication domain, with some sort of manually curated list, is not a place where we want to be IMO. If we really want to make search work, we can always just add it to the API endpoint allowlist (for REST APIs there is no way to enable/disable them one by one, but easy to add a hook for that, and it would make sense beyond this one use case).

In T381096#10365976, @Krinkle wrote:

It looks like we need Ajax support to api.php for T380552: Fix client-side password validity check on SUL3 (Api base URL broken), possibly the fix there could also address rest.php.

It does address it, mw.Rest uses mw.config.get( 'wgScriptPath' ) just like mw.Api. But that doesn't really help since we have disabled non-authentication-related endpoints.

I don't see a great way to make that work in a general sense we have contradictory requirement right now. E.g. authentication forms should submit to the auth-domain/enwiki/w/ and other things to canonical-domain/w/. With a base tag, this would work so long as we take care of our own forms.

Authentication forms aren't particularly "our own" - some are generated in AuthManager, some elsewhere in MediaWiki core (e.g. password reset), some in extensions (e.g. WebAuthn enrollment). We don't have an easy way of mass-affecting them, while search is I think the only form that we'd want to go the other way.

But disabling search seems to me like a generally useful thing to do anyway. It's just a distraction during authentication.

This seems like a fairly important issue to fix.

@JTweed-WMF / @Tgr - Growth will be working on Account Creation improvements next quarter and I would love to see this completed. Let me know if Growth needs to consider prioritizing this.