Hi Ovid,

I just supplied the bit I am worried about to keep it as short as possible and was just grepping a convenient perl file on my system. Yes to proof of concept. The @ lines data just get munged and goes back to the browser with links to the found stuff so that is/should be fine.

The get_data() routine is just your usual bread and butter Perl. As the user does not interact directly with it I did not think it necessary to be inclued. Here it is anyway.

sub get_data {
    my $file = shift;
    open (FILE, "<$file") or die_nice("Oops can't read $file: $!\n");
    if ($flock) {
        my $count = 0;
        until (flock FILE, LOCK_SH) {
            sleep 1;
            die_nice("Can't lock file '$file': $!\n") if ++$count >= $
+timeout;
        }
    }
    my @file = <FILE>;
    close FILE;
  return \@file;
}
[download]

My main worry was null byte; "\n..."; "/@file; `rm rf`; #" type hacks. These won't work but are there others? Oh the die_nice() prints the usual "Sorry the system can not respond to your request due to routine maintenence, please try again later." back to the browser and sends the admin the real message ;-)

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Not that you are going to worry about this too much if the search input is only reused on a page returned to that very user, but you may want to do something to escape any HTML that is included in the user input before it gets sent back to the browser (in an HTML document). At best, it will goof up the display (i.e. the browser will interpret the tags as tags). At worst, if one user is allowed to enter input that will be output to another user there is significant potential for foul play (javascript, pictures of Barney... people do weird stuff if this hole is open).