Page MenuHomePhabricator

Add a rate limiting class to session JWTs
Closed, ResolvedPublic

Description

Using the mechanism from T399198: Define standard JWT session data for supported session types, we should add rate limiting information to every session JWT (to be used by T405544: Add support for rate limiting rest gateway routes to api-gateway helm chart). The current OAuth 2 JWTs use an integer "number of requests per hour" value, but that's very inflexible, so we'll probably add some sort of rate limiting class instead, and use configuration (puppet, I guess) to translate that to specific numbers in Varnish / Envoy.

This task is to define where that rate limiting class should come from.

Event Timeline

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

[mediawiki/extensions/WikimediaEvents@master] [POC] Add higher traffic rate limiting class for noratelimit users

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

@JTweed-WMF @daniel any thoughts on what the specific classes should be?

@JTweed-WMF @daniel any thoughts on what the specific classes should be?

We defined a couple of classes for the initial rool-out of rate limiting in Envoy, but they are basically what happens if we *don't* have the rate limit class in the jwt. The preliminary limit classes are:

  • no-limit: internal/testing use, disables rate limit entirely
  • anon: no user identity, uses client IP instead
  • cookie-user: user name from unverified cookie
  • jwt-user: user identity from validated JWT (in progress)

Classes that seem useful to me that we might want in a JWT generated by mediawiki include:

  • mw-autoconfirmed
  • mw-community-bot

The problem is that MW knows these things per wiki, but we'd need a global class. This needs to be integrated with centralauth somehow.

We could also have classes for app tokens:

  • wmf-wikipedia-app

We could also have classes assigned at the edge, in a header, for requests without a jwt:

  • wmf-cloud-services
  • wmf-known-bot
  • wmf-suspected-scraper...

CentralAuth can check crosswiki groups via CentralAuthUser::getLocalGroups() (example). Not sure that works for implicit groups though.

Reassigning this temporarily to set up some rate limiting classes for testing. Will assign back afterwards.

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

[mediawiki/extensions/OAuth@master] Indicate owner-only status to OAuth 2 access token claims hooks

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

Change #1210597 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] Indicate owner-only status to OAuth 2 access token claims hooks

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

Change #1175247 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Add higher traffic rate limiting class for bots

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

Let's just mark this as done. We'll probably want to change the specifics, but it should be very simple to do so (and if not, we can reopen).