I understand the technique, I just cant think how that would be useful. So if failed logins hits a threshold, and they quite reasonably try to login again after 4 minutes, it resets the 5 minute wait? What if someone kept trying every 30 seconds. That is quite a reasonable scenario, and if I was a user I would get pretty annoyed with your system for locking me out for more than 5 minutes. The 5 minute timeout should be from the first failure that crossed your threshold, and never increment.
If the logins fail again after the 5 minutes, start another 5 minute block. Smooth logins for a busy site are mandatory. You cannot confuse or block a real user in any way, or you will very likely lose them. On Sat, Sep 12, 2009 at 2:05 AM, Jehiah Czebotar <[email protected]> wrote: > > if you were using a key to track say, failed logins, by ip address and > you wanted a persistent lock until there were no attempts for 5 > minutes you would keep calling incr() so you have a failure count, > resetting the expiration each time and then when it's not touched for > 5 minutes it would fall off > > that is a scenario that isn't possible right now > > On Fri, Sep 11, 2009 at 1:13 AM, Clint Webb <[email protected]> wrote: > > Why are you putting an expiry on a key you are incrementing and > > decrementing? I cant think of a situation where I would want to expire > a > > counter (other then letting it fall out the LRU). > > > > In fact, the only situation I can think of that could use an expiry would > > follow the way it currently works. Ie, I'd set a key with a 5 minute > > expiry, and then keep incrementing it for whatever reason, and then after > 5 > > minutes, the key goes away and I create another one. I do this for > > tracking surges of hits from particular IP's (although I dont use 5 > > minutes). > > > > I cant think of any reason where I would want to give the key a new > expiry > > that couldn't be taken care of by the LRU evictions. > > > > On Fri, Sep 11, 2009 at 1:20 AM, Adam Lee <[email protected]> wrote: > >> > >> On Thu, Sep 10, 2009 at 9:31 AM, Dean Michael Berris > >> <[email protected]> wrote: > >> > > >> > Hi Guys, > >> > > >> > I recently checked the documentation about the memcached protocol and > >> > while looking at supporting it in my C++ client, I'm looking at a > >> > situation where I'm not sure whether it's possible to set the > >> > expiration of a key through the incr/decr commands. From the > >> > documentation, it seems that there's only a way to increment and > >> > decrement, but not set the expiration of the key being > >> > incremented/decremented. > >> > > >> > Is this by design? Should I file for a feature request for an > >> > incr/decr that also updates the expiration of a cache key? > >> > > >> > This feature would be really useful for tracking keys -- maybe > >> > tracking activity within a certain period of time. So something like > >> > this algorithm would be easily supported: > >> > > >> > 1. The first time something happens, set a key to 0 in memcached, > >> > expires in X seconds > >> > 2. The next time something happens, increment the key (update the > >> > expiration to X seconds) -- if the increment fails, that means the key > >> > has expired, set the key to 0 again > >> > 3. If the incremented value is higher than a certain number, then > >> > you can do something about it (maybe there's abusive behaviour going > >> > on, maybe a clicker bot or something) > >> > >> We use this exact functionality, with one key difference-- we set this > >> expiration when we initialize the counter, but it doesn't get updated > >> when we incr/decr. This is useful to implement any sort of counter-- > >> rate limiting certain user actions, tracking occurrences of specific > >> activities, etc... > >> > >> We ended up just building a generic McCounter class that you > >> initialize with an expiration. It has get/set/incr/decr and takes > >> care of all the behind-the-scenes work to make sure that the value > >> exists in MC before trying to incr, etc. It's a super simple class > >> and has proved infinitely useful-- perhaps you also want to build > >> something along these lines. > >> > >> -- > >> awl > > > -- "Be excellent to each other"
