[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.