Closes #261 (closed)
This implements a rate-limit feature
-
Documentation (or see below) -
Customizable limits per endpoints / type of operation / client (anonymous/authenticated) -
/api/v1/rate-limitendpoint to expose limits and current usage of the client -
X-RateLimit-*headers in response to expose limits and current usage of the client -
Handle 429 answer in the front-end and display a proper error message
Default limits as found in common.py are rather high to avoid disruption on existing pods. We can tweak them depending on the feedback we receive, and admins can also customize these individually, by adding a THROTTLING_RATES=<scope1>=<rate1>,<scope2>=<rate2> environment variables. E.g, to to increase the number of reports anonymous users can submit: THROTTLING_RATES=anonymous-reports=100/h.
cc @funkwhale/reviewers-python @funkwhale/reviewers-front
Front-end result
Swagger Documentation
Depending on server configuration, pods running Funkwhale 0.20 and higher may rate-limit incoming requests to prevent abuse and improve the stability of service. Requests that are dropped because of rate-limiting receive a 429 HTTP response.
The limits themselves vary depending on:
- The client: anonymous requests are subject to lower limits than authenticated requests
- The operation being performed: Write and delete operations, as performed with DELETE, POST, PUT and PATCH HTTP methods are subject to lower limits
Those conditions are used to determine the scope of the request, which in turns determine the limit that is applied.
For instance, authenticated POST requests are bound to the authenticated-create scope, with a default limit of
1000 requests/hour, but anonymous POST requests are bound to the anonymous-create scope, with a lower limit of 1000 requests/day.
A full list of scopes with their corresponding description, and the current usage data for the client performing the request
is available via the /api/v1/rate-limit endpoint.
Additionally, we include HTTP headers on all API response to ensure API clients can understand:
- what scope was bound to a given request
- what is the corresponding limit
- how much similar requests can be sent before being limited
- and how much time they should wait if they have been limited
| Header | Example value | Description value |
|---|---|---|
X-RateLimit-Limit |
50 | The number of allowed requests whithin a given period |
X-RateLimit-Duration |
3600 | The time window, in seconds, during which those requests are accounted for. |
X-RateLimit-Scope |
login | The name of the scope as computed for the request |
X-RateLimit-Remaining |
42 | How many requests can be sent with the same scope before the limit applies |
X-RateLimit-Available (if X-RateLimit-Remaining is 0) |
1568126189 | A timestamp indicating when the client can retry |
X-RateLimit-AvailableSeconds (if X-RateLimit-Remaining is 0) |
3543 | How many seconds to wait before a retry |
X-RateLimit-Reset |
1568126089 | A timestamp indicating when X-RateLimit-Remaining will return to its higher possible value |
X-RateLimit-ResetSeconds |
3599 | How many seconds to wait before X-RateLimit-Remaining returns to its higher possible value |