Goal
Keep people from spamming and DoSing the backend.
Description
People shouldn't be able to make more than a certain number of requests per time period; anything over that should return a 429 Too Many Requests.
Authed requests are relatively easy to ratelimit -- allow a certain maximum number of requests per user. We need to query the database to get user details anyway; may as well get one more column. This applies to POST /login as well, except that we get the user from the login details, not the Authorize header.
Unauthed GET requests probably don't need to be ratelimited. GET endpoints only ever query things, and so can be handled extremely quickly and efficiently with little to no overhead (read-only mirrors can handle them while a write-only master handles updates). Worst case, we can always ratelimit on IP address or similar.
The only point of concern is user registration: It's unauthed, and it modifies the database, so it can't be simply handled by throwing more computers at the problem. I'm genuinely not sure how to handle this; maybe just ratelimiting by IP and globally? i.e. if more than 10 users are created in a second, ask people to wait for a minute? There's a reason this is tagged discussion wanted.
Alternatives
- Not doing it - We... kinda need this. Comic-Con is very large and very public; we should do our best to prevent the inevitable harassment. We can scale the ratelimit down during perf and beta testing to see if it negatively affects user experience, but I doubt it will -- most people will probably make 3-4 requests a second at most, depending on their browser.
Additional notes
99% of this can be implemented in a Filter or Interceptor completely transparently, without anything else needing to know about it. The only difficulty I see is the user registration. We need to figure out how to effectively ratelimit that. I'm sure there are people who have done it before who we could talk to, though.
Goal
Keep people from spamming and DoSing the backend.
Description
People shouldn't be able to make more than a certain number of requests per time period; anything over that should return a 429 Too Many Requests.
Authed requests are relatively easy to ratelimit -- allow a certain maximum number of requests per user. We need to query the database to get user details anyway; may as well get one more column. This applies to
POST /loginas well, except that we get the user from the login details, not theAuthorizeheader.Unauthed
GETrequests probably don't need to be ratelimited.GETendpoints only ever query things, and so can be handled extremely quickly and efficiently with little to no overhead (read-only mirrors can handle them while a write-only master handles updates). Worst case, we can always ratelimit on IP address or similar.The only point of concern is user registration: It's unauthed, and it modifies the database, so it can't be simply handled by throwing more computers at the problem. I'm genuinely not sure how to handle this; maybe just ratelimiting by IP and globally? i.e. if more than 10 users are created in a second, ask people to wait for a minute? There's a reason this is tagged discussion wanted.
Alternatives
Additional notes
99% of this can be implemented in a
FilterorInterceptorcompletely transparently, without anything else needing to know about it. The only difficulty I see is the user registration. We need to figure out how to effectively ratelimit that. I'm sure there are people who have done it before who we could talk to, though.