Relatedly, we plan to do T206012, which in my view means that CentralAuthTokenSessionProvider should never allow editing site JS.

I thought this might be a side-effect of T207557: Don't count initial login as valid for any operation that requires reauth, i.e. that we might be counting the creation or use of catoken as "login time" and thus "too soon" for reauth.

Looking at the code, that doesn't seem to be the reason.

	securitySensitiveOperationStatus () {
		// ..
		if ( $session->canSetUser() ) {
			// ..
			$last = $session->get( 'AuthManager:lastAuthTimestamp' );
			if ( $id !== $aId || $last === null ) {
				$timeSinceLogin = PHP_INT_MAX; // Forever ago
			} else {
				$timeSinceLogin = max( 0, time() - $last );
			}
		} else {
			$timeSinceLogin = -1;

			$pass = $wgAllowSecuritySensitiveOperationIfCannotReauthenticate; // [ 'default' => true ]
			if ( isset( $pass[$operation] ) ) {
				$status = $pass[$operation] ? self::SEC_OK : self::SEC_FAIL;
			} elseif ( isset( $pass['default'] ) ) {
				$status = $pass['default'] ? self::SEC_OK : self::SEC_FAIL;
			} else {
				throw new \UnexpectedValueException(
					'$wgAllowSecuritySensitiveOperationIfCannotReauthenticate lacks a default'
				);
			}
		}

Where Session::canSetUser > Provider::canChangeUser > CentralAuthTokenSessionProvider::canChangeUser returns false.

And this flaw with $wgAllowSecuritySensitiveOperationIfCannotReauthenticate is indeed tracked at T419353 per @matmarex.

In T423537#11827796, @Catrope wrote:

Relatedly, we plan to do T206012, which in my view means that CentralAuthTokenSessionProvider should never allow editing site JS.

That sounds like it may break some workflows… First thing that comes to mind is tools for syncing gadgets across wiki (I don't know if such a thing exists, but if it doesn't, it should). Personally I've also edited site CSS (not sure if I ever did it for JS) with mw.ForeignApi while cleaning up old junk as a volunteer global interface editor. Disallowing it only for CentralAuthTokenSessionProvider, and allowing e.g. OAuth over CORS, may be less problematic.

(Not saying that you mustn't do it, just that there might be some trade-offs)

Btw, if we find some workflows that we don't want to break, I also thought that we could allow cross-wiki editing with the reauth requirement (after T419353 is done) by "inheriting" the lastAuthTimestamp from the browser cookie session when creating the centralauthtoken.

This was fixed by explicitly checking for CentralAuthTokenSessionProvider, right?

Change #1306011 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Allow SessionProviders to disable security-sensitive operations

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

Change #1306012 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/extensions/CentralAuth@master] Disable all security-sensitive operations when centralauthtoken is used

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

In T423537#11831841, @matmarex wrote:

In T423537#11827796, @Catrope wrote:

Relatedly, we plan to do T206012, which in my view means that CentralAuthTokenSessionProvider should never allow editing site JS.

That sounds like it may break some workflows… First thing that comes to mind is tools for syncing gadgets across wiki […] with mw.ForeignApi while cleaning up old junk as a volunteer global interface editor. […]

https://www.mediawiki.org/wiki/Synchronizer does exactly this, which is how some popular gadgets stay in sync (example: https://www.wikidata.org/wiki/Q132165799), which has stopped working.

Now that we have better handling for reauthentication, and now that we've already made it global-ish on wiki farms (change 1285894), I think the correct solution here would be for centralauthtoken-based sessions to "inherit" the elevated login state from the session which generated the token.