how about just not making the info public?

there really isn't any other reliable way to do it. whatever method you use to prevent people from spending more than 20 minutes on the search results page can be easily circumvented by the user just hitting Save in their browser and storing a local copy. IP limits are largely ineffective (IP's are not that hard to forge or just change every couple minutes if they have control over their local network). i once consulted on what basically was a large poll site and one of my tasks was to develop strategies to block people from voting multiple times. the straightforward approach of tracking IP addresses wouldn't cut it in the real world; what was eventually needed was some rough AI that would detect and flag input patterns that look suspicious (lots of the same vote coming in rapid succession or from similar/sequential IP addresses, etc). if they're determined, there's very little you can do without expending a huge effort.

is this data that the people listed added to your site or was it public data that you collected? have the people listed in the database consented to having their info listed?

what is your ultimate goal in blocking these people? is it to protect the people in the database from being called by insurance companies or are you somehow losing customers/revenue because they're only loading the pages once?

anders pearson

Why not apply this technique to your website? for each search you could generate a "nondeterminate" number that a user has to enter each time they do a search.

The code would last only a few mins and would not be reusable in the short term.

In HTTP there is no state, so a user cant keep your directory "open" in a literal sense. If what you mean is a search page is being refreshed all the time, that's easy: Embed a hidden (nondeterminate) value in your page and hook it up with a created time in a database, when the user hits refresh, compare the hidden token with the stored timestamp, and return a timeout page if the difference is over your threshold.

A Non Determinate Value could mean:

use Digest::MD5 qw(md5_hex);

my $ndv = md5_hex('53cr3t 57r1n6'.$$.rand().localtime() );
my $smallndv = substr($ndv, 0, 4);
[download]

merlyn did a column once on anti robot stuffing of vote polls. The idea was to prevent automated techniques from making multiple votes for a poll. The technique used was generating a code on an image and getting the user to enter the code along with their vote.

See jcwren's A little fun with merlyn for a way to bypass such a script :-).

On the first point, this *can* be done with a little work, although it's not perfect. Use a little server-side code to create a 1-time-code for use in the search script. Store these codes in a database along with a timestamp of when they were created, and if the code is older than 30 minutes, fail the search. It won't stop them from reloading a new page, but would keep them from using the same page over and over again. You could also do the same thing with cookies, which would be a tiny bit harder for the user to work around.

Perhaps a better solution is to take the database 'private' and require registration before use - you could then track who did what, and manually blacklist the abusers.

None of that is impregnable, but the goal of any security is simply to make it too much trouble for the would-be attacker compared with the value of the data.

Sales people are persistant and have a lot of time on their hands, but are not usually very technical. Combine HTTP basic authentication with a registration process and a cookie to track # of searches, and you'd probably block 90% of them.

you may want to require a user account be setup to view more than 10 results/page and 10 mile radius. make the account openings take a day, place caps, or generate reports of suspicious activity. disable account based on abuses of the caps or your judgement based on the reports. make sure it takes a day to re-activate the account once the user contacts you to get it restored. etc...

as long as you offer the information, someone can build a system to harvest it. the best you can do is make it impractical so they look somewhere else.

Mildew Hall.. Home of PurePostPro and other Perl goodies!
Not only oysters create Pe[a]rls