Open johakoch opened 6 months ago
I like the idea. How would you define the order? We could inspect expressions (especially those using request.context), like we do to order request sequences. Or would you use the order of references in the access_control list?
Or would you use the order of references in the access_control list?
I guess that's the order in which access controls are (already) applied.
I would apply the ordered list - no magic reordering.
Should we reply with some additional headers like https://github.com/sashabaranov/go-openai/blob/master/ratelimit.go#L10 ? This could also be interesting for our BE limiters.
Should we reply with some additional headers like https://github.com/sashabaranov/go-openai/blob/master/ratelimit.go#L10 ? This could also be interesting for our BE limiters.
See also
Let's start with a simple implementation that just uses status 429 to communicate current overuse.
The key
in the proposal is the "key" feature :).
Without it, rate limiting is almost useless. We could even make it a mandatory field.
Is it worth to provide a non-dynamic alternative to the key (which has to be evaluated in cty land) to be more efficient or make typical use-cases simpler? Example:
by_header = "API-Key"
by_client_ip = true
Anyways, we can start with the dynamic key and introduce those optimized shortcuts later once typical use is clear.
We could implement a rate limiter as an access control, e.g.:
429
if the request is blockedbackend
key
expression value, e.g. depending onrequest.<property>
or a JWT claim (request.context.at.sub
, if used after an "at"jwt
access control)It could be handy to add more
request.
sub-properties, e.g. from goRequest.RemoteAddr
if available.