Closed nicokaiser closed 5 years ago
Totals | |
---|---|
Change from base Build 39: | 0.7% |
Covered Lines: | 34 |
Relevant Lines: | 34 |
If you think this PR is useful, I can try to also implement this for tj/node-ratelimiter to make it consistent again.
why not read the value directly from redis?
why not read the value directly from redis?
That would be possible, but the "sliding window" effect would be gone then. When reading the value directly from Redis (with zcard
), the count is only reset to 0 at duration
after the last get
call. When using get
(or the PR implementation), the count is decreased duration
after the first get
call.
Hello @nicokaiser, can you implement it at tj/node-ratelimiter? I interested in be 1:1 replacement
Any updates on this? It seems like essential functionality :)
Sorry for the delay! Added into the codebase, also I'm going to add the example as part of the documentation.
Thanks for all 🙂
Oh yay! Thanks a bunch @Kikobeats!
In some scenarios it might be useful to be able to read the current "remaining" value for a limiter.
In this example, new login attempts are rejected when more at least 10 unsuccessful login attempts happened in the last 60 seconds.
This is done with a new
decrease
parameter that controls if theremaining
value should actually be decreased (default:true
) or if the request is only done to read the current value.What do you think?