Sam Tregar wrote:
> On Tue, 2 May 2006, Michael Peters wrote:
> 
>>>     # set the table name to use for storing hits
>>>     $rate_limit->table('rate_limit_hits');
>>
>> It might be nice if there was a reasonable default for this table name.
>> Apache::Session and CGI::Session both default to 'sessions' but can be
>> changed.
> 
> Sure, a default for this makes sense.
> 
>>>     # call this runmode when a violation is detected
>>>     $rate_limit->violation_mode('too_fast_buddy');
>>>
>>>     # or, run this callback
>>>     $rate_limit->violation_callback(sub { ... });
>>
>> Is there any way for these methods to be able to know how many times
>> they were abused, or how long the user will need to wait to try again? I
>> remember a project where the $client wanted the user to receive a
>> message like "You have done this too many times... Please wait x minutes
>> and try again."
>>
>> Maybe you can pass the needed information to the subs being called or
>> make it available in either params() or the $rate_limit obj.
> 
> Passing along information to the violation mode sounds like a good
> idea.  I wonder though how you would compute X for "wait X minutes and
> try again."  You could set X = to timeframe, but that would be
> pessimistic.  The accurate number would be timeframe - time since
> first considered event, since after that you've got at least one more
> chance.

I would leave the calculation up to the user, but it would need all of
that information passed into it in some sort of structure.

>> Another use for this module might be to limit arbitrary actions and not
>> necessarily run modes. The same $client above also wanted a limit on the
>> number of failed logins that could happen for a given username in a
>> given time period. So it wasn't just run mode access since a successful
>> login shouldn't matter. Maybe something like the following:
>>
>>  $rate_limit->record(
>>    user   => $user_id,
>>    action => 'failed_login'
>>  );
> 
> Hmmm.  How would that method indicate a violation?  It's not obvious
> to me how that would interact with 'violation_mode', for example.

Good point. Maybe a check_violation() companion to record_hit()?

  my %limit_args = ( user => $user_id, action => failed_login );
  $rate_limit->record_hit(%limit_args);
  return $self->slow_down_buddy
    if( $rate_limit->check_violation(%limit_args) );

> Another idea that was suggested to me is to allow a hit to be
> revoked.  This might be useful to allow validation errors to not count
> as hits for rate-limiting.  Something like:
> 
>   $self->rate_limit->revoke_hit()
>     if $errors_found;

That would make sense too. I don't want you to use this for spam, but if
you're just really bad at filling in my form you can try as many times
as you like.

Not to make it too bloated but maybe also a revoke_all_hits() method.
This would let me do something like "Allow only 5 failed login attempts
in 10 minutes. If they successfully login, reset the counter". Not too
important though.

  revoke_all_hits( user => $user, action => $action )

-- 
Michael Peters
Developer
Plus Three, LP


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/[email protected]/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to