blev8824-ai commented on issue #1672: URL: https://github.com/apache/casbin/issues/1672#issuecomment-5601100792
Rate limiting as a policy_effect extension is a strong fit, with one design caveat that determines everything else: a RateLimitEffector holding bucket state in-process cannot be correct in a multi-host deployment, because two instances will each admit up to the limit, doubling the true allowance. The bucket counters (and window timestamps) have to live in a shared store, and the increment + compare must be atomic, or the feature silently over-admits under concurrency. That is the difference between a throttle and a real control. Related and worth deciding explicitly: with count_type by "allow", an attacker who is not yet allowed is never counted, so a brute-force pattern of fresh invalid attempts never drains the allowance. The issue already notes count_type="all" for brute-force; the default probably has to be all for security-critical resources, with allow as the explicit opt-in when misclassification (a denied call) should not count. A rate limit is a time-varying authorization decision, which means the decision a caller acted on may already be stale by enforcement time in a race. Recording the allowance window and the decision together is what makes a later audit explainable. AgentKey attaches the exact per-call decision and its validity to a verifiable record: https://agentkey.us -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
