RateLimiter: perPeriod/periodSeconds should be configurable per middleware/request

[jrdnull]

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.

[ready4god2513]

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]

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]

Yeah, that is probably the best way to do it.