Repository navigation
RateLimiter: perPeriod/periodSeconds should be configurable per middleware/request #23
Description
Brought up in the unified api doc:
Price Plans per product may sell increased Rate Limits as a feature which needs to be taken in to account
Currently the perPeriod/periodSeconds would be shared between multiple instances of the middleware, this should be configurable so you can apply different rate limiters on different endpoints.
To meet the requirements of the quote above you would need to check the session to see if they had a higher rate limit, so perhaps it should change to use a function to return the perPeriod/perSeconds so it can be different depending on the session similar to the GetKey callback.
Activity
[-]RateLimiter: perPeriod/periodSeconds should be configurable per middleware[/-][+]RateLimiter: perPeriod/periodSeconds should be configurable per middleware/request[/+]ready4god2513 commentedon May 30, 2018
Anyone have a good idea on how to do this without destroying the database? If the account level needs to be checked then it means that we are authing before running the rate limit check which would mean that a malicious actor could send large numbers of requests causing spikes on our infrastructure.
I suppose installations should be cached is the simplest answer.
arp242 commentedon May 30, 2018
The way I had planned to do it in deskedge (but haven't done yet) is to cache it in Redis; so that way you only need to get it from the DB once.
Caching in a map would be even better/faster, but cache invalidation for that in case someone changes their plan will be a bit more involved/ugly.
ready4god2513 commentedon May 30, 2018
Yeah, that is probably the best way to do it.