In T412350#11466139, @Tgr wrote:

I don't think there's an easy way to handle a bypass option in the UI.

I don't think there's an easy way to handle a bypass option. You can bypass all permission checks with UltimateAuthority, but not permission checks from specific compontents. Letting power users unconditionally bypass checks with a permission similar to abusefilter-bypass-blocked-external-domains / sboverride / sfsblock-bypass / etc would be easy though.

Motivated by T410521: Add com.blogspot.wikikamus: to list of allowed OAuth2 URI schemes.

Actually not entirely expected - I think there should still be a small trickle of manual-forced writes from JWT cookie expiries for logged-in users, just much less than before? But we have zero now.

The manual-forced writes are gone as expected, but the total writes are still pretty high. Not sure what to think about it.

@Jdforrester-WMF Writing an extension for deployment says

Add your extension to the json make-wmf-branch release tool at least two weeks prior to your target date for enabling on the Beta Cluster.

but that was probably written with the old train deploy schedule in mind and one week is enough, right?

Same as T411654: MediaWiki periodic job startupregistrystats failed.

Either we need a REST endpoint for checking whether the user is logged in (the REST version of action=query&meta=userinfo) or we need to get rid of $wgRestAllowCrossOriginCookieAuth and make sure that the Action API and REST API are always in sync wrt CORS support. The latter makes more sense to me but I'm probably missing the reason why it was done this way in the first place.

The problem seems to be that mw.ForeignRest uses mw.ForeignApi.checkForeignLogin() to check whether it needs to use a centralauthtoken, and that check does succeed since it uses the action API (for which CORS is enabled via a separate setting).

CORS is currently disallowed but ForeignApi should be falling back to centralauthtoken and that's apparently not working.

Are they caching image metadata? Maybe it's worth following up with the largest reusers.

Probably not relevant anymore. (Feel free to reopen the task if you still want to be added!)

Yeah, sorry, there's no editing capability whatsoever. I can disable old versions if you want.

Done.

https://docs.google.com/presentation/d/1nWurSh82kw9EeSn1v4TrEFRpoe8udQbWZu7agwHPMf0/edit (from T407529: Conduct Comparative Review: Web vs Native Apps vs Reference OAuth sign-in patterns) has some comparison of OAuth authz dialogs of other websites and some design explorations / recommendations, from the POV of the Wikimedia mobile apps.

@MarioB applications that require no privileges beyond identity verification require no approval. (The last application needed private data access so that was different.)

There is no way loading user groups can take 11 seconds, without some sort of deadlock. It's a straightforward SELECT using the primary key, returning a few dozen rows at most.

Same issue as T411654: MediaWiki periodic job startupregistrystats failed.

Could also have a soft rate limit ("someone has already requested recovery for this email address, are you sure you want to do it again?").

Probably should be added to Herald although I don't expect a lot of tasks. @OWresch-WMF @JTweed-WMF what do you think?

See also T149672: OAuth: don't abort if the username does not exist on project which is the same issue for OAuth.

See also T208443: User cannot log in with OAuth on a wiki before visiting that wiki directly (which is about making API requests; this one is about the authorization workflow).

See also T208443: User cannot log in with OAuth on a wiki before visiting that wiki directly (which is about the authorization workflow; this one is about making API requests).

This seems like a good idea (with "app[lication] passwords"; access token would be really confusing as that's used mostly in the OAuth context). Not sure we'll get around to it though; I think we are more interested in directing people to use OAuth.

So this is essentially a duplicate of T410764: MediaWiki periodic job startupregistrystats-mediawikiwiki failed (and will be fixed by T390972: Restart CronJobs on failure of the service mesh I think?) but we can't close it because the bot would just reopen it.

In T411550#11426253, @Izno wrote:

Theoretically this could be resolved by putting the tag after the first bar character in the template, but then your style tag impacts sortability (I think).

I guess the problem here is that the style tag isn't really inside the table (in which case it would have to be hoisted, or "refostered" per the HTML5 spec which I'm sure Parsoid follows) but inside a HTML attribute, at which point it isn't even a tag anymore.

Per team discussion today, MediaWiki-Platform-Team will own the extension as a framework. The individual hooks etc. will be owned by the team that needs them, similar to how it's today for WikimediaEvents with its OWNERS.md file.

Chrome is blocking the setting of cross-site cookies without SameSite=None now:

Doesn't it use these values in production? I think that would be the service mesh?

Math needs a config change.

The dashboard URL structure is pretty obscure so I added it to the docs on wikitech.

In T410764#11432069, @Clement_Goubert wrote:

If you rename them, the next time the alert fires, it will create a new task instead of appending to the existing open one.

Hm. I thought AuthManager makes sure it is a primary user but I must have misread the code because for login it acutally doesn't. I suppose there isn't really a strong reason to, most authentication providers wouldn't change user data on login.

Do we understand why the cookie is defunct? It's called unconditionally in persistSession() as

$this->setLoggedOutCookie( $session->getLoggedOutTimestamp(), $request );

so I guess $session->getLoggedOutTimestamp() always returns 0? Should we get rid of that (and generally the loggedOut field in session metadata) as well? The other thing it gets used for is setting User::$mTouched for anonymous users.

Varnish has this snippet, if we are dropping the cookie, we should probably drop it as well:

// Users that just logged out, should not get a 304 for their
// (locally cached) logged in pages.
if (req.http.If-Modified-Since && req.http.Cookie ~ "LoggedOut") {
    unset req.http.If-Modified-Since;
}

CentralAuthUser::getBlocks() isn't called in relatively performance-sensitive situations but CentralAuthUser::getLocalGroups() is.

For non-confidential apps, there's also T323855: OAuth 2.0 non-confidential clients cannot use refresh tokens without client secret.

In general I think it would be nice to rename these auto-generated tasks and put something about the specific failure reason in their title. They are going to be very unhelpful when searching for related issues in the future.

Normal and error output isn't differentiated at all though, filed T411663: Normal output and error output from Wikimedia scheduled maintenance scripts should be logged differently in Logstash about that.

It seems like this happened in some form? The output for at least some scripts is now present in Logstash.