Add a clear_rate/reset_rate function
nicksanders opened this issue · comments
I would like to be able to use ex_rated for login attempts.
On successful login I would like to delete/reset the bucket
Would you be interested in a pull request adding a function like
ExRated.clear_rate("LOGIN:192.168.1.20", 60_000)
Hi. I guess I would want to understand a bit more about why you need to clear them manually.
Couldn't you just let ex_rated cleanup after itself with the built in pruning functionality and set a short bucket timeout when you initialize the gen server? Why does leaving the bucket around until it gets pruned cause an issue?
e.g. set :timeout to 15 min so that no bucket will last longer than that after the last login attempt at which point the bucket would disappear lazily on its own when the prune process reaps buckets every minute (or whatever interval you want).
Also, if we did do this would you need to pass in the bucket name and a value (60_000 in your example) or just the bucket name? In which case perhaps an api like 'ExRated.delete_bucket("bucket-name")' might be more concise?
Maybe I'm missing something. Happy to hear more about your ideas for this.
If I'm doing check_rate for an IP address I would like to be able to reset the count so one person's logins don't affect someone else on that same IP and I would like to do that as soon as they successfully login. The other way to do it is have a function that checks but doesn't increment the count like "read_rate" and then only check_rate on failed login?
ExRated.delete_bucket("bucket-name") is a much better idea.
Would it be possible to change check_rate to return milliseconds left till next key on error?
ie {:error, milli_secs_left} instead of {:error, limit}
The limit isn't much use as we already know that and I could use milli_secs_left let people know how long their login is locked out for?
I would accept a pull request for delete_bucket.
For returning milliseconds left I would also be fine with that but perhaps
it should be added onto the existing response. Otherwise it's a potentially
breaking change that would creep in to people's code with the value being
returned suddenly having a different meaning. Perhaps what should come back
is the full context of how many checks could be done, in what time period,
and with x ms remaining.
Please keep the pull requests separate.
Thanks!
On Wed, Dec 9, 2015 at 01:51 Nick Sanders notifications@github.com wrote:
If I'm doing check_rate for an IP address I would like to be able to reset
the count so one person's logins don't affect someone else on that same IP
and I would like to do that as soon as they successfully login. The other
way to do it is have a function that checks but doesn't increment the count
like "read_rate" and then only check_rate on failed login?ExRated.delete_bucket("bucket-name") is a much better idea.
Would it be possible to change check_rate to return milliseconds left till
next key on error?ie {:error, milli_secs_left} instead of {:error, limit}
The limit isn't much use as we already know that and I could use
milli_secs_left let people know how long their login is locked out for?—
Reply to this email directly or view it on GitHub
#5 (comment).