[ic] Possible bug: Too many new ID assignments for this IP address

[John1]

In October 2004 I posted:
http://www.icdevgroup.org/pipermail/interchange-users/2004-October/041215.html
explaining what I thought was a bug which can result in *permanently* 
blocked access to Interchange sites from ISPs who use proxy servers.

To avoid this problem we are currently running with "RobotLimit 0", so it's 
not really causing us a problem any more (although it would be nice not to 
have to use RobotLimit 0).

Here is the sub count_ip code (which is still the same as it was in October 
2004):

sub count_ip {
 my $inc = shift;
 my $ip = $CGI::remote_addr;
 $ip =~ s/\W/_/g;
 my $dir = "$Vend::Cfg->{ScratchDir}/addr_ctr";
 mkdir $dir, 0777 unless -d $dir;
 my $fn = Vend::Util::get_filename($ip, 2, 1, $dir);
 if(-f $fn) {
  my $grace = $Vend::Cfg->{Limit}{robot_expire} || 1;
  my @st = stat(_);
  my $mtime = (time() - $st[9]) / 86400;
  if($mtime > $grace) {
   ::logDebug("ip $ip allowed back in due to '$mtime' > '$grace' days");
   unlink $fn;
  }
 }
 return Vend::CounterFile->new($fn)->inc() if $inc;
 return Vend::CounterFile->new($fn)->value();
}

I believe crux of the problem is that this code is checking the last 
*modified* time which actually has the effect of *permanently* blocking 
large ISPs who use a relatively small number of proxy servers.

##########  snippet from my post in October 2004:
So, here is the problem:  any IP address that is typically allocated more
than 1 session id in a 24 hr period will never get its addr_ctr file
expired.  i.e.  There needs to be a full 24 hr period without access from
the same IP address before the addr_ctr file will be deleted thus
re-allowing access from that IP address.  For large ISPs using a relatively
small number of proxy servers this may *never* happen, and so access
from their proxy servers is permanently blocked.
##########

i.e.  "RobotLimit X" is supposed to block accesses from IP addresses that 
have been allocated more than X SessionIDs in a 24 hour period, but in 
actual fact what it is really doing is *permanently* blocking IP addresses 
that have been allocated more than X SessionIDs without there ever being a 
*gap* of more than 24 hours before allocation of the next SessionID.

A fuller explanation can be found in my original post:
http://www.icdevgroup.org/pipermail/interchange-users/2004-October/041215.html

Thanks