Secure login area for documents but how to secure documents themselves

[dprichard]

I built a login area with a document manager.  It works great and all and all the pages are secure.  My question though if the pages are protected by php and you can't get to them, how do you keep someone from linking to the document directly.  Since the document is not going to process the php and check for credentials when they put in the direct link to the document.

[dbo]

Store them in a database as a blob. Then do your php validation and if they should have access to them then you use mime type headers to have php act as if it is the said document.

[dprichard]

Is that going to give me a performance hit over storing them in the file system.  One of the clients has 10k users.

[dbo]

Extra connections/calls to the database are obviously to take more time, but it should be minimal. However, if what you're trying to accomplish is a must... you don't really have any other options.

[micah1701]

you don't need to store them in a database to keep them secure.

 

just store them in a .htaccess protected folder on your site.

 

then when a logged in user wants to view a document, send them to a "document reader" script that makes sure their authorized then calls the file and presents it to the user:

 

<?php
if(!$_SESSION['authorized_to_view_files']){
   exit("sorry you can not view this file");
  }

$filename = "/actual/path/to/secured/file/name.pdf"; //either hard code this value or pass variable to this script and have some code look up the actual location based on the passed variable.

header('Content-type: application/pdf');
header('Content-Disposition: attachment; filename="whatever_you_want_to_call_it.pdf"');
readfile($filename);
?>

[dbo]

Yeah... you can do this but if you're dealing with a very large number of files it's going to be a management nightmare.

[micah1701]

Yeah... you can do this but if you're dealing with a very large number of files it's going to be a management nightmare.

 

not trying to pick a fight, but how is it any more difficult then keeping the application in a blob?

 

just create a db table with columns like:

 

fileID  (example: 42392918)

fileTye (PDF or DOC)

filePath (/location/of/original)

filesize

total_downloads

any_other_data_you_want_to_store

 

then when the user calls:

 

your_document_reader.php?fileID=42392918

 

the script goes to the database, finds the location of the secured original, uses the docType field to figure out which mime type to use in the header, updates the download count in the database, does whatever else you want it to do and then sends the file to the users browser.

 

its the same number of steps as your method, minus storing the bloated blob in the database.

[dbo]

I guess just b/c you're relying on the host allowing you to use .htaccess files which not all do. Assuming you automate the file upload process you are doing the insert and then having to move the file into the appropriate folder. Have to remember to document how it's being protected so that if someone comes in behind you or you move hosts... otherwise the documents are out there wide open, etc. You've got complete control once it's stored in the database. I guess I also just think it's cleaner than maintaining a file structure.

[trq]

heaps of different opinions around for the subject of blob vs filesystem. If you want mine, I say databases are for storing relational not binary data. On top of that, the filesystem will allways be quicker a database does (after all) eventually need to write the data to the filesystem anyway.

[dbo]

heaps of different opinions around for the subject of blob vs filesystem. If you want mine, I say databases are for storing relational not binary data. On top of that, the filesystem will allways be quicker a database does (after all) eventually need to write the data to the filesystem anyway.

 

Which filesystem? The local file system aka the server or the client's file system aka cache?

 

Cause databases... even MySQL store the data in the file system in a very similar way to how it is w/o the database. You just have more options for indexing/encryption/compression etc. As far as I can tell it doesn't get re-written to the file system, it's simply served up when asked for. The only extra overhead should really be the connection.

 

If you're talking about the cache... there's really no difference from one to the next.

[neel_basu]

Sotre them into a folder and add this .htaccess file in it.

deny from all

and create a doc_router.php file that reads and gets contents from that folder upon validation and serves the cpntents of those file.

[MadTechie]

Personally i use micah1701 idea.. it works well, only differents is i use a folder outside of the public_html folder as PHP can read from their but it can not be browsed.. as for storing in the database. i'm on thorpe's side if the fence 100%.