[Zope] Using Zope to manage and serve large files
ianb at colorstudy.com
Fri Oct 31 18:09:01 EST 2003
On Oct 31, 2003, at 4:21 PM, Jim Penny wrote:
> On Fri, 31 Oct 2003 23:47:36 +0200
> Heimo Laukkanen <huima at 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
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 at colorstudy.com | http://blog.ianbicking.org
More information about the Zope