Hello all.

I have a client who wants to be able to restrict access to a PDF file to a
specific user. They want a control panel where they can create a user with
username/password and upload the PDF. So far so good.

But what is the best way to restrict access to the PDF ? I was thinking of
storing it above the root so that it was not in the public domain, when the
user requests it, prompt for username/password and then copy the file with a
random filename to a public place. Then delete is straight afterwards.

There has to be a better way though ?

thanks

Zoe

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in message
news:kN%0i.1430$7l6.542 [at] newsfe7-win.ntli.net...
> Hello all.
>
> I have a client who wants to be able to restrict access to a PDF file to a
> specific user. They want a control panel where they can create a user
with
> username/password and upload the PDF. So far so good.
>
> But what is the best way to restrict access to the PDF ? I was thinking
of
> storing it above the root so that it was not in the public domain, when
the
> user requests it, prompt for username/password and then copy the file with
a
> random filename to a public place. Then delete is straight afterwards.
>
> There has to be a better way though ?
>
> thanks
>
> Zoe
>
>
What type of access? File system; php script; web?
Vince

"Vince Morgan" <vinharAtHereoptusnet.com.au> wrote in message
news:46448baa$0$28584$afc38c87 [at] news.optusnet.com.au...
> "Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in message
> news:kN%0i.1430$7l6.542 [at] newsfe7-win.ntli.net...
>> Hello all.
>>
>> I have a client who wants to be able to restrict access to a PDF file to
>> a
>> specific user. They want a control panel where they can create a user
> with
>> username/password and upload the PDF. So far so good.
>>
>> But what is the best way to restrict access to the PDF ? I was thinking
> of
>> storing it above the root so that it was not in the public domain, when
> the
>> user requests it, prompt for username/password and then copy the file
>> with
> a
>> random filename to a public place. Then delete is straight afterwards.
>>
>> There has to be a better way though ?
>>
>> thanks
>>
>> Zoe
>>
>>
> What type of access? File system; php script; web?
> Vince

Would be via a link, so PHP. I am looking at .htaccess now though - do you
think this would be better ?

>

On Fri, 11 May 2007 15:16:32 GMT, in alt.php "Zoe Brown"
<zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net>
<kN%0i.1430$7l6.542 [at] newsfe7-win.ntli.net> wrote:

>| Hello all.
>|
>| I have a client who wants to be able to restrict access to a PDF file to a
>| specific user. They want a control panel where they can create a user with
>| username/password and upload the PDF. So far so good.
>|
>| But what is the best way to restrict access to the PDF ? I was thinking of
>| storing it above the root so that it was not in the public domain, when the
>| user requests it, prompt for username/password and then copy the file with a
>| random filename to a public place. Then delete is straight afterwards.
>|
>| There has to be a better way though ?
>|
>| thanks
>|
>| Zoe


Thinking outside the square - why not password protect the PDF file
itself? The average user will not be able to open the file without the
correct password and there fore will not be able to view it. Then it
doesn't matter where the file is stored.
------------------------------------------------------------ ---
jnorthau [at] yourpantsyahoo.com.au : Remove your pants to reply
------------------------------------------------------------ ---

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in message
news:kN%0i.1430$7l6.542 [at] newsfe7-win.ntli.net...
> Hello all.
>
> I have a client who wants to be able to restrict access to a PDF file to a
> specific user. They want a control panel where they can create a user
with
> username/password and upload the PDF. So far so good.
>
> But what is the best way to restrict access to the PDF ? I was thinking
of
> storing it above the root so that it was not in the public domain, when
the
> user requests it, prompt for username/password and then copy the file with
a
> random filename to a public place. Then delete is straight afterwards.
>
> There has to be a better way though ?
>
> thanks
>
> Zoe
>
>

I've seen PHP programs like PHPBB that do a good job of managing
permissions, but not quite what you would need. If you just needed to
control access to a few people it could be simple, but if you are trying to
manage people that may subscribe/unsubscribe over time then there's a lot
more to worry about.

Depending on what resources you had access to, it may be easier setting up
the permission on your web server or the .htaccess file. If you had limited
access and/or needed something more complex you may be able to find a
publicly available PHP/MySQL authentication solution you can download and
install or can build you own.

Tom
--
Newsguy.com - Express Accounts - 30 GB $9.95 / month

"Jeff North" <jnorthau [at] yahoo.com.au> wrote in message
news:lv69435eo8sh1a92tsg5o1rkkn8t5holld [at] 4ax.com...
> On Fri, 11 May 2007 15:16:32 GMT, in alt.php "Zoe Brown"
> <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net>
> <kN%0i.1430$7l6.542 [at] newsfe7-win.ntli.net> wrote:
>
>>| Hello all.
>>|
>>| I have a client who wants to be able to restrict access to a PDF file to
>>a
>>| specific user. They want a control panel where they can create a user
>>with
>>| username/password and upload the PDF. So far so good.
>>|
>>| But what is the best way to restrict access to the PDF ? I was thinking
>>of
>>| storing it above the root so that it was not in the public domain, when
>>the
>>| user requests it, prompt for username/password and then copy the file
>>with a
>>| random filename to a public place. Then delete is straight afterwards.
>>|
>>| There has to be a better way though ?
>>|
>>| thanks
>>|
>>| Zoe
>
>
> Thinking outside the square - why not password protect the PDF file
> itself? The average user will not be able to open the file without the
> correct password and there fore will not be able to view it. Then it
> doesn't matter where the file is stored.

because the PDF file is not owned by the client, they want to upload a file
(that they source from elsewhere) and just press a few buttons, they dont
want to open and edit the file. So everyting needs to be done in php.

> I've seen PHP programs like PHPBB that do a good job of managing
> permissions, but not quite what you would need. If you just needed to
> control access to a few people it could be simple, but if you are trying
> to
> manage people that may subscribe/unsubscribe over time then there's a lot
> more to worry about.
>
> Depending on what resources you had access to, it may be easier setting up
> the permission on your web server or the .htaccess file. If you had
> limited
> access and/or needed something more complex you may be able to find a
> publicly available PHP/MySQL authentication solution you can download and
> install or can build you own.

Thanks, I think I have decided to go down the .htaccess route. This will
mean that the user will have to enter a username and/or password which will
give them access to their link (they need to access the pdf via the website)
and then once they access the file they will be prompted by the sever for
username/password again. I think my client will live with this.

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in
news:H831i.3223$o42.590 [at] newsfe3-win.ntli.net:

> Thanks, I think I have decided to go down the .htaccess route. This
> will mean that the user will have to enter a username and/or password
> which will give them access to their link (they need to access the pdf
> via the website) and then once they access the file they will be
> prompted by the sever for username/password again. I think my client
> will live with this.

Sure, they may live with it, but you must recognize its far from ideal.
A username+password system is good, but two systems? For retrieving one
file? It sounds to me like you are forcing your user to deal with this
problem instead of tackling it yourself on the programming side.

Storing the file above the www root and streaming it via PHP is the best
solution for what your client wants... when your system "gets" the PDF
via PHP upload, store it in a folder above 'www' and keep the info in a
database 'files' table (the file name, the real location on the server,
and a bunch of random characters to serve as a key instead of using an
auto-increment ID).

Then, you have a file called "streamFile.php".... your user clicks on
the link "streamFile.php?key=3197fhduabsd", and your script looks up the
file according to the key, then uses readfile(); or a custom function to
stream the file to the browser....

Or, you could go with .htaccess entirely. But using a combo of
..htaccess, sessions and databases to control user access is more often a
headache than not. And asking people to enter a username/password more
than once is incredibly annoying and bad user interface design.

Good luck!

In article <3201i.6866$eY1.1099 [at] newsfe2-win.ntli.net>, Zoe Brown wrote:
> >> I have a client who wants to be able to restrict access to a PDF file to
> >> a specific user.

I think you're right. You don't need to put them in the root, just "above" the
html directory. Then you can validate your user & give 'em the file, or not.

Mark

> Then, you have a file called "streamFile.php".... your user clicks on
> the link "streamFile.php?key=3197fhduabsd", and your script looks up the
> file according to the key, then uses readfile(); or a custom function to
> stream the file to the browser....

great, can you tell me a bit more about streaming the file to the browser,
would this work for pdfs ? i presume this wont mean that they will abel to
rightclick and download though ?

but isn't you approach just as risky as having the pdf file in the public
domain with a random name.

> Or, you could go with .htaccess entirely. But using a combo of
> .htaccess, sessions and databases to control user access is more often a
> headache than not. And asking people to enter a username/password more
> than once is incredibly annoying and bad user interface design.

Thanks for your input, I agree 100%. I thought that the .htaccess thing was
the right way forward but am now reconsidering.
Thanks again.

Zoe Brown wrote:
>> Then, you have a file called "streamFile.php".... your user clicks on
>> the link "streamFile.php?key=3197fhduabsd", and your script looks up the
>> file according to the key, then uses readfile(); or a custom function to
>> stream the file to the browser....
>
> great, can you tell me a bit more about streaming the file to the browser,
> would this work for pdfs ? i presume this wont mean that they will abel to
> rightclick and download though ?
>
> but isn't you approach just as risky as having the pdf file in the public
> domain with a random name.
>
>> Or, you could go with .htaccess entirely. But using a combo of
>> .htaccess, sessions and databases to control user access is more often a
>> headache than not. And asking people to enter a username/password more
>> than once is incredibly annoying and bad user interface design.
>
> Thanks for your input, I agree 100%. I thought that the .htaccess thing was
> the right way forward but am now reconsidering.
> Thanks again.
>
>
Maybe you should just consider having a PHP Script which does the
managment of the .htaccess users.
This way you can use the .htaccess to protect a directory, and you will
have a php Script that will add/delete users that has access to this
directory (.htaccess /.htpasswd).
I think I have seen once a similar script named phpaccess.php. Maybe you
can still find it around!

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in
news:Qzl1i.9904$H4.5066 [at] newsfe2-gui.ntli.net:

>> Then, you have a file called "streamFile.php".... your user clicks on
>> the link "streamFile.php?key=3197fhduabsd", and your script looks up
>> the file according to the key, then uses readfile(); or a custom
>> function to stream the file to the browser....
>
> great, can you tell me a bit more about streaming the file to the
> browser, would this work for pdfs ? i presume this wont mean that
> they will abel to rightclick and download though ?

they still might be able to rightclick and download, though they won't get the real filename in that case (they will probably be prompted to download the file "streamFile.php?key=asdifoh" even though its a PDF).

yes, you can stream any type of file to the browser: http://ca.php.net/readfile is the PHP manual page, though if there is any chance your streamed files will be greater than 2MB, you should use the "readfile_chunked" function on that page (posted by chrisputnam at gmail dot com), it's a winner (ive used it on several sites).


> but isn't you approach just as risky as having the pdf file in the
> public domain with a random name.

not at all... because you are storing a random 'key' along with the filename, someone would have to guess the key. I tend to use 16-character keys. I am not worried in the slightest that someone will be able to guess a key like "6ruyhfn7k34bfdwq" and have it be valid. Obviously, your "streamFile.php" key should first check to make sure the key is valid (ie: it is in the database).



> Thanks for your input, I agree 100%. I thought that the .htaccess
> thing was the right way forward but am now reconsidering.
> Thanks again.

someone else suggested using PHP to control the .htaccess file. this is certainly possible, but again, with that scenario you will have two different types of access settings for a single website (if I recall correctly, your users are already logging in via a MySQL database). It's easier overall to keep a single type of access setting.

Sorry it took two days to respond, but I've been using my suggested method on a few different major websites for years, and it's easy / reliable.

In fact, here is my streamFile.php code, though I've removed some of my custom error functions and kept some custom SQL functions in. But you should get the point. Please excuse any word-wrapping:

-----


<?php
session_cache_limiter("must-revalidate");
session_start();

/*
************************************************************ *****
* *
* Streaming a file to the user's browser: *
* *
************************************************************ *****
*/


connectToDatabase(); //custom function

[at] $vFileKey = trim(mysql_real_escape_string($_REQUEST['vID']));

if ($vFileKey=="") { //no key?
echo "no such file.";
exit;
}

//pickup the file
$row = singlequery("SELECT FileName,FilePath FROM ProjectFiles WHERE FileKey='$vFileKey'"); //singlequery is a custom function
$vFilePath = $row['FilePath'];
$vFileName = $row['FileName'];

if($vFilePath=="") {
echo("There has been an error retrieving this file. Please call us and we will assist you.");
exit;
}

if(!is_file($vFilePath)) {
echo("We cannot deliver this file to you, as it is not on the server. Please call us and we will assist you.");
exit;
}

session_write_close(); //allows them to continue browsing the website and start other downloads while this one is going on


//now we stream the file, prompting a download
header("Cache-control: private");

// We'll be forcing the user to download it
header('Content-Type: application/octet-stream');

// It will be called whatever the file name is called, and given the attachment Disposition to force the download
header('Content-Disposition: attachment; filename="'.$vFileName.'"');

//this custom function is a good one for streaming files to browsers; it does not suffer from a 2MB limit like "readfile();" does
readfile_chunked($vFilePath);




//function used in this page (see above)

function readfile_chunked($filename,$retbytes=true) {
$chunksize = 1*(1024*1024); // how many bytes per chunk
$buffer = '';
$cnt =0;
// $handle = fopen($filename, 'rb');
$handle = fopen($filename, 'rb');
if ($handle === false) {
return false;
}
while (!feof($handle)) {
$buffer = fread($handle, $chunksize);
echo $buffer;
ob_flush();
flush();
if ($retbytes) {
$cnt += strlen($buffer);
}
}
$status = fclose($handle);
if ($retbytes && $status) {
return $cnt; // return num. bytes delivered like readfile() does.
}
return $status;

}

?>

>> but isn't you approach just as risky as having the pdf file in the
>> public domain with a random name.
>
> not at all... because you are storing a random 'key' along with the
> filename, someone would have to guess the key. I tend to use 16-character
> keys. I am not
> worried in the slightest that someone will be able to guess a key like
> "6ruyhfn7k34bfdwq" and have it be valid. Obviously, your "streamFile.php"
> key should
> first ?check to make sure the key is valid (ie: it is in the database).

But using your logic i could create a pdf file called 6ruyhfn7k34bfdwq.pdf,
store the filename along with username/password in the DB and then the only
wany someone could access it would be to guess the filename. I dont see how
your methid is safer ?

> In fact, here is my streamFile.php code, though I've removed some of my
> custom error functions and kept some custom SQL functions in. But you
> should get the point. Please excuse any word-wrapping:

thanks

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in
news:lk32i.12268$H4.3485 [at] newsfe2-gui.ntli.net:

> But using your logic i could create a pdf file called
> 6ruyhfn7k34bfdwq.pdf, store the filename along with username/password
> in the DB and then the only wany someone could access it would be to
> guess the filename. I dont see how your methid is safer ?

True, you could rename the PDF, but surely the original PDF file name is
of some value for your end user (ie: someone being prompted to download
"floor_plans.pdf" versus "12983dohfsdof7.pdf")

And also true, you could just put the PDF file in a *directory* that is
randomly named...

The only advantages to my suggested method over any of these two is

1) No extra folders/directories are being created on the server

2) The PDF is *guaranteed* not to be spidered and/or accessible via the
web root

3) A user *must* be logged in to retrieve the file. If you go with the
file/directory renaming route, your user can bookmark the link to the
secret PDF and pass it on to whomever they wish. With my proposed
system, "streamFile.php" checks to see if the user is logged in before
allowing the file to stream, and for users who aren't on your system -
well, they can't download the file at all.


When a client says to me 'these are sensitive documents that should not
be seen by anyone except authorized people', i automatically place them
outside of any web directory, and use my suggested method. habit i
guess, but it works, is secure, and achieves all my goals.

Good luck!

Good Man <heyho [at] letsgo.com> wrote in
news:Xns9930B5E3AE347sonicyouth [at] 216.196.97.131:

> 3) A user *must* be logged in to retrieve the file. If you go with
> the file/directory renaming route, your user can bookmark the link to
> the secret PDF and pass it on to whomever they wish. With my proposed
> system, "streamFile.php" checks to see if the user is logged in before
> allowing the file to stream, and for users who aren't on your system -
> well, they can't download the file at all.

I should mention that the code for "streamFile.php" that I posted had the
"is the user logged in?" test removed for brevity :)

"Good Man" <heyho [at] letsgo.com> wrote in message
news:Xns9930B67EA98F5sonicyouth [at] 216.196.97.131...
> Good Man <heyho [at] letsgo.com> wrote in
> news:Xns9930B5E3AE347sonicyouth [at] 216.196.97.131:
>
>> 3) A user *must* be logged in to retrieve the file. If you go with
>> the file/directory renaming route, your user can bookmark the link to
>> the secret PDF and pass it on to whomever they wish. With my proposed
>> system, "streamFile.php" checks to see if the user is logged in before
>> allowing the file to stream, and for users who aren't on your system -
>> well, they can't download the file at all.
>
> I should mention that the code for "streamFile.php" that I posted had the
> "is the user logged in?" test removed for brevity :)

thanks for the time you have taken to respond to my questions. It has been
a great help. am I allowed to cut your code and use a a starting point for
mine ? Oh and - probably daft question, can I use the smae method for all
file types ?

"Zoe Brown" <zoenaomibrown [at] N-O-S-P-A-A-Mtesco.net> wrote in
news:ZUg2i.14202$%9.1618 [at] newsfe7-gui.ntli.net:

>
> "Good Man" <heyho [at] letsgo.com> wrote in message
> news:Xns9930B67EA98F5sonicyouth [at] 216.196.97.131...
>> Good Man <heyho [at] letsgo.com> wrote in
>> news:Xns9930B5E3AE347sonicyouth [at] 216.196.97.131:
>>
>>> 3) A user *must* be logged in to retrieve the file. If you go with
>>> the file/directory renaming route, your user can bookmark the link
>>> to the secret PDF and pass it on to whomever they wish. With my
>>> proposed system, "streamFile.php" checks to see if the user is
>>> logged in before allowing the file to stream, and for users who
>>> aren't on your system - well, they can't download the file at all.
>>
>> I should mention that the code for "streamFile.php" that I posted had
>> the "is the user logged in?" test removed for brevity :)
>
> thanks for the time you have taken to respond to my questions. It has
> been a great help. am I allowed to cut your code and use a a starting
> point for mine ? Oh and - probably daft question, can I use the smae
> method for all file types ?

of course, use the code, you might want to spice it up a bit with that
'login check' depending on how your access is set up. and yes, you can use
the same method for all file types... good luck!