The first step to creating a secure online data repository is to have the actual documents stored in a location that cannot be accessed by the public. Here are three very different approaches:

1. Store the file in a blob field of a database. The disadvantage of this is that the server is put under slightly more strain than if copying a file directory from the file system. The advantage is that the security is probably the best out of the three options here.
2. Store the file in the server's file system using a large number coded physical filename. Like the blob field database storage this physical file is never directly exposed to the client and only the server application knows where the file is. The process of giving the client access to this file is covered below.
3. Rather than attempting to hide the direct file URL specified by the server's operating system, allow the references to be known to the client but create access permissions at the operating system level or hosting software level. It might appear that this is the simplest approach and for this reason it is commonly used, but I would like to raise two problems. Firstly this approach is not portable and that reduces security; if you are moving your application to another operating system human errors can easy occur relating to how the file permissions are configured. Secondly the username and password login might be difficult to integrate tightly with your web application's native username and password system. A good web application should have a single login for the entire session and you do not want to see new dialogue boxes appearing when trying to access certain files.

We will concentrate on how the private files are passed to the right users by following the first and second approaches above.

If the file is stored in the database then files that are not tens of megabytes can be retrieved to the memory of your server application code and the file itself can be returned as the HTTP response. The user would then see the upload options appear in much the same way that you would see if you typed direct file reference into your browser's address bar. Your HTTP response will usually begin with the line "Content-type: text/html" and this can be changed to the appropriate message for the type of file being downloaded by the user, followed by the file contents. That is the end of the story for the first approach.

For the second approach, in which the file is stored as a coded filename in the file system, you will still need a database table that holds information about all stored files. In particular you will need to know (1) the original physical filename and (2) the coded physical filename on the server. The hyperlink to download the file will not be a direct file reference but instead a reference to your web application with the instructions to perform the following:

1. Check from your database whether the logged in user has access to the file in question.
2. Make a copy of the coded file to a temporary location on the server. Create a directory with a randomly coded name and place the file copy in this directory.
3. Rename the file to the original non-coded filename.
4. Return an HTML page as the response which includes a hyperlink to the temporary file.

The directory creation in step 2 prevents someone from continually attempting to download a URL using a known filename until someone permitted to download it 'opens the door'. The strength of this approach is that it is both secure and fast and can be used with very large files. The weakness is that you will need to add a strategy for deleting the temporary directories and files and ensure that they are not deleted while the user is still downloading. A reasonable approach is to simply run a delete routine every few hours.

Julian Cochran
DigitalScores
www.digitalscores.com