Skip to content

funkwhale
funkwhale
Merged
Opened by Eliot Berriot@eliotberriot💬5 of 5 tasks completed5/5 tasks
Report abuse

: Rate limiting

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-limit endpoint 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

Peek_2019-09-11_10-41

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
Rate limiting headers
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
Edited by Eliot Berriot