Please, make sure your filename contains a version number. For security reasons you will never be able to upload a file with the same name again (not even after deleting it).

UPDATE (10 or so hours later) ...

First, it's not that hard. maverick, JackHammer, bliz, and myself (under the management of eduardo) built an authentication site (that also offered customizable authorization) in 3 days using nothing but CPAN modules from the Apache::Auth family. It is not that hard and does not take a terribly long time to do. (And to be honest, instead of that, i would consider using a content management tool such as Slash or even PostNuke.)

Second, you mentioned that you plan on adding this functionality at a later point in time. Why not do it now? This is something i keep asking you time and time again. Why not do it now? What is going to happen to this system when you do add users to your site? You are going to have to modify your file upload code to accomodate them. Why not just do it now? I have witnessed your frustration at trying to port your existing CGI apps over to Apache::Registry when kind folks here at PM suggested you go straight to mod_perl. In the time it took you to work out countless bugs (and claim that the tool was broken) you could have first done some research and testing with smaller 'Hello world' type examples and had you site running under a more robust system. I have witnessed your frustration trying to coax CGI into output the HTML you wanted when i myself kept recommending a templating solution. In the time it took you to work out the kinks and intricacies of CGI.pm, you could have done a little homework and been up and running with HTML::Template, a little more and you could already have had site running with TT2. I recommend you drop this file upload feature and add users instead. It will be time well spent.

So, is there anything wrong with allowing anonymous users to upload files to your site? Of course not, not with the proper precautions. But, you are making more work for yourself in the long run, and you not practicing the art of True Laziness. I wish you well and hope your site is a success.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

security-wise, the lines:

and

open(SAVEPDB,">$directory/${file_name}_${md5file}")
             or die $!;
[download]

concern me. it's a good idea to use taint mode and do something more like:

if($file_name =~ /(\w+\.?\w+)$/) {
   $file_name = $1;
} else {
   die "invalid and possibly dangerous characters in filename."
}
[download]

where you explicitly limit the characters that can be in the filename.

anders pearson

Using a hash function to avoid namespace collisions won't work if you just hash the filename. If 'H' is your hash function, H(x) == H(y) if x == y. You will still get the same hash value from identical filenames. To mix things up, perhaps hash the filename concated with something non-static like the return value of localtime or something (md5_hex($filename . localtime)). You could also use crypt()'s hash function and add random salt each time a file is uploaded.

Of course, this is all assuming you're intent on using hashes. However, I see no point in doing so. You will not be able to go backwards from the hashed value to the original filename -- only if the user must enter a filename for your script to retreive (so you can hash that and look for the hash value in the DB). And even that will only work if you do not add salt to the filename to prevent collisions. So a hash seems silly to me.

I would highly suggest -- especially for a large-scale project like this -- storing the files in SQL blobs instead of in real files. A malicious user can put whatever characters they want in the filename, but you don't need to worry with an SQL implementation. Using the hash is a noble way to create filenames that are "safe", but like I said, the hash will be one way, and it seems like you want the filename back. Plus, you really have to be on your guard when you let CGI scripts write to files and especially create new files.

May I suggest altering your table so that the sample_id field is AUTO_INCREMENT -- let SQL take care of the primary key for you. This way, you can have multiple files with identical names, just refer to them always by their unique id (myscript.pl?file=42). You wouldn't have to try to avoid namespace collisions (unless there were other reasons for doing so). If you really need a directory structure to these files, create a column sample_is_folder (boolean) and a sample_parent column so you can set up a tree-ish structure. Well, there would obviously be more to it than that, but hopefully you get the idea. .... Oh yes, and of course add the BLOB/LARGEBLOB column for the uploaded files if you choose that route.

Good luck!