On Oct 31, 2003, at 4:21 PM, Jim Penny wrote:
On Fri, 31 Oct 2003 23:47:36 +0200 Heimo Laukkanen <huima@iki.fi> wrote: Well, the main problem is simply making sure that the customer cannot possibly guess the filename. So, use the Secure Hash Algorithm (SHA) and your own site-based secrets.
That is, given a filename, calculate SHA(secret_1 + file_name + customer_name + secret_2). Save the file in a customer specific (apache accessible) directory, using the SHA as the filename. Then put a dummy index.html in that folder, something like <html><head></head><body>No Peeking!</body></html>
You could also use this signing process to allow a CGI script to download the file. Like you redirect the user to a URL like /downloader.cgi? customer=custname&filename=somefile.html&time=103943&auth=934a975f Where time is the result of int(time.time()), and auth is SHA(customer_name + filename + str(int(time.time())) + secret). Then the CGI script confirms the SHA, makes sure the timestamp isn't too old, and then lets the user download the file. The actual files are kept outside of Apache's docroot, but readable by the CGI script. Somewhat higher overhead because of CGI vs. pure Apache, but CGI scales fine for large files. Unlike using filenames, users won't be able to bookmark or link to file locations, and they won't be able to get any caching. This could be good or bad. If you really wanted caching, you'd put the timestamp and signature in a cookie, then call something like /downloader.cgi/custname/filename. You'd still have to handle caching in your script (I think setting modification-date(?) and checking if-modified-since would be enough). The result would be kind of weird, though -- browsers could cache files, but they couldn't bookmark them, and the reliability of passing authentication information like that in cookies isn't very good. Using URL parameters is definitely more reliable. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org