Hi,
I have policies to documents and I want to put it on a web PGP portal for download to the employee with a password protected access.
If the URL for a policy is www.myWeb.com/policies/document1.pdf, I don't want any one to see this url when downloading or when viewing the page source.
What's the best way to do it?
Thanks,
Jassim
How important is this? Ultimately, if they are going to request the resource they are going to have to have a URL for it; once they have the URL they can do what they want with it - given enough motivation.
If your worry is that an unauthorised employee might be able to guess the URL, then you can try say, serving the PDF document with HTTP Basic authentication. If that is too inconvenient, you could generate a long random string for the PDF filename, though unless you are monitoring for brute force attempts, in theory a user could run a script that eventually guesses the filename.
Of course, once an employee already has the PDF document, he/she can just save and email it to someone else, so trying to protect against that by hiding the URL would be futile anyway.
wha about generating a temporary url for the document and expire it when the session is closed? is this possible? how to do it?
Just make a PHP file, do whatever auth or logging you need to, and then:
$path="/secret/path/readable/by/www/server/";
$filename = "Secret.pdf";
$file=$path.$filename;
$dlname = "This_file_is_not_a_secret_file_no_way.pdf";
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header("Content-type: application/pdf");
header("Content-Disposition: attachment; filename=$dlname");
readfile($file);
exit;Dalecosp has described how you handle access to protected documents. You write your PHP code to authenticate someone. E.g., ask them for a password, check a cookie, or whatever. Then you use the code he's posted to spit out the file. The user is not downloading the file directly via apache, every byte of the file is being routed through the php script and the PHP script won't spit out the file if the user hasn't supplied the necessary authentication. Think of the PHP script as the gate keeper for the file. It's important that you keep the file ('secret.pdf' in dalecosp's example) outside of the web root so that it's more secure.
In the source code will still be html, unless you do it somehow through Javascript :queasy:
hunterthompson;11052139 wrote:In the source code will still be html, unless you do it somehow through Javascript :queasy:
No: it's done via a PHP script - it will give the file only to authenticated (logged in) users - nothing to subvert via javascript or html.
sneakyimp;11051833 wrote:Dalecosp has described how you handle access to protected documents. You write your PHP code to authenticate someone. E.g., ask them for a password, check a cookie, or whatever. Then you use the code he's posted to spit out the file. The user is not downloading the file directly via apache, every byte of the file is being routed through the php script and the PHP script won't spit out the file if the user hasn't supplied the necessary authentication. Think of the PHP script as the gate keeper for the file. It's important that you keep the file ('secret.pdf' in dalecosp's example) outside of the web root so that it's more secure.
I think using a cookie is the least safe option right? So I would go with using a password. Maybe having a unique passwords sent via email first before they can access the page?
Sixty5;11053403 wrote:I think using a cookie is the least safe option right? So I would go with using a password. Maybe having a unique passwords sent via email first before they can access the page?
A "typical" authentication scheme, as implemented in PHP, involves [man]sessions[/man], which are implemented in a couple of ways. While not 100% foolproof, it's good enough for general purposes and should work well for the perceived problem the OP described. Cookies and passwords really aren't related, unless you mean "set a cookie and read it and if it exists give access to the protected resource", which is, indeed, a pretty dumb idea. 
dalecosp;11053417 wrote:A "typical" authentication scheme, as implemented in PHP, involves [man]sessions[/man], which are implemented in a couple of ways. While not 100% foolproof, it's good enough for general purposes and should work well for the perceived problem the OP described. Cookies and passwords really aren't related, unless you mean "set a cookie and read it and if it exists give access to the protected resource", which is, indeed, a pretty dumb idea.
Not so fast! The way session work is to have Page1.php ask for the password which submits to Page2.php which checks the password and sets a cookie with a session id. Then on Page3.php (or PageN.php) the PHP code looks for that cookie, retrieves the session id from it, and then decides whether or not to consider the user logged in based on the session id that was stored in the cookie. Without the cookie (or propagating the session id in the query string or some other way), you have to provide the password every time you want to do something sensitive.
sneakyimp;11053423 wrote:Not so fast!
Yes, of course, but as a programmer I can write PHP sessions without ever using a $_COOKIE variable or even knowing that they exist, because PHP does that for me (unless the configuration is set not to), which was my point.
So, while it doesn't hurt to know how PHP does session work (and you make reference to both methods, via a cookie and via use_trans_sid), it's not necessary to think about when writing basic code, and we may muddy the waters in our discussions with less-experienced users when we get overly pedantic about such things. 
And, since I have now out-pedantic'ed you and mentioned it out loud, let it be known that use_trans_sid is not secure, can allow sessions to be hijacked, and should NOT be used across a wide-area-network like the Internet, and probably shouldn't be used anywhere these days.
Well-said all around! And yes we probably don't want to confuse anyone, but how sessions actually work is a pretty important security-related consideration -- and pedantry is so gloriously satisfying.