Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • funkwhale funkwhale
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 380
    • Issues 380
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 22
    • Merge requests 22
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • funkwhalefunkwhale
  • funkwhalefunkwhale
  • Merge requests
  • !877

: Rate limiting

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Agate requested to merge rate-limiting into develop Sep 11, 2019
  • Overview 12
  • Commits 9
  • Pipelines 3
  • Changes 20

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 Sep 11, 2019 by Agate
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: rate-limiting