The idea is to offer a way for Clowder admins to configure ratelimits to the platforms that they manage.
| Table of Contents |
|---|
Base Implementation Options
Here are some options for how to go about implementing rate limits in Clowder from a high-level.
Option 1: NGINX Ratelimiting
See https://www.nginx.com/blog/rate-limiting-nginx/ for an example of how to configure these limits
...
- NGINX configuration is notoriously complex
Option 2: Clowder API Ratelimiting
See https://github.com/sief/play-guard for a possible example of a generic plugin for handling this
...
- Ratelimits would be on a per-instance basis - e.g. if you are running 4 replicas of Clowder, a user who is ratelimited on one machine could repeat their request to reach another machine where they are not ratelimited (is this acceptable?)
Option 3: Route53 Ratelimiting?
I looked into applying the ratelimit one level above NGINX, going to Amazon's Route53 which I believe currently handles our DNS resolution (among other things).
Sadly, it looks like Route53 applies its own ratelimiting, which is not necessarily configurable or even exposed to the user.
Error-Handling Options
From Google:
The HTTP 429 Too Many Requests response status code indicates the user has sent too many requests in a given amount of time ("rate limiting").
A Retry-After header might be included to this response indicating how long to wait before making a new request.
My recommendation would be to stick with this error code if we find that it is commonly used to indicate that a user is ratelimited.
Other Concerns
- How can we tell the difference between a user being ratelimited vs being blocked by the firewall (HTTP 429 should only be a symptom for ratelimit?)