[vern ali quinox]

Just a comment on the request limiting stuff...

It appears that the 1-request-per-hour limit is imposed per IP address -- a fact which I accidentally discovered from a pc which sits behind a firewall using network address translation (NAT). (If I'm completely wrong on how it works, please disregard the rest of this post.)

With the way NAT is configured on that network, each outbound TCP connection gets its own source IP/port assigned to it, so successive HTTP requests can appear to come from multiple systems even though it's just one browser generating them.

The problem is that if the rule is just '1 request per hour per ip address', then anybody behind a NAT firewall that works as described above can make as many requests as there are addresses in their outbound NAT pool. For folks listening on large networks using NAT (which is rather common), that could be a significant number (>100).

Adding a cookie with a 1-hr timeout per request might make it slightly less easy to circumvent the intent of the 1-request-per-hr limit. Sure, folks could delete the cookie, but if you kept the 1-per-address rule in place as well, you'd at least make it require a bit more effort for folks to circumvent the intent of the policy.

Short of using cookies, even limiting the number of requests per address block (say, class-C sized blocks) per hour might help reduce the abuse, since NAT typically uses contiguous address blocks.

This is a common problem with any network-based authentication mechanisms that are intended to be transparent to the user -- while it's trivial to determine how many IP addresses are hitting your server, it is less easy to figure out how many machines are really behind that, and even harder to map all the way back to humans sitting at keyboards. Short of prompting the user to identify themselves, there's nearly always going to be a way to abuse the intended policy.