file_put_contents outside of web directory

[DeX]

I have a portal system I built that allows users to generate a quote PDF and save it onto the server so they can send the link to a customer for review. Is it common practice to leave the PDF directory web accessible or should it be one level above the web directory? These quotes do need to be viewed by the public since the salesmen simply send the URL to the customer for review but I've seen it done both ways. Thanks.

[requinix]

If the PDFs can be publicly viewable, as in anybody on the internet should be able to see them (if they had the link), then go ahead and leave the directory web-accessible.

 

If not, and I suspect not since these are bills that users are sending to people, then don't. Put the directory somewhere else and then make a PHP script which authenticates the user and then serves (outputs the contents of) the PDF.

[benanamen]

If there is any personal information in the document you should secure it. If you leave it in a public directory, at least put an index file in there to stop directory browsing if you have it enabled.

[Jacques1]

You can actually have both a public link and tight access control by using share links. For example, your customer gets this link:

https://yoursite.com/quotes.php?token=7c043ece6892c4869db68d3e824ef5bc

All tokens are stored in the database together with their status (valid/invalid) and the file they map to. When the script receives a token, it tries to look it up in the database, and if everything is OK, it displays the corresponding file.

 

This provides maximum convenience for your customers (it's just like a normal file link), but at the same time you can control the file access. You can make the links expire after a while, you can manually disable them in case they're leaked etc.

[seandisanti]

You can actually have both a public link and tight access control by using share links. For example, your customer gets this link:

https://yoursite.com/quotes.php?token=7c043ece6892c4869db68d3e824ef5bc

All tokens are stored in the database together with their status (valid/invalid) and the file they map to. When the script receives a token, it tries to look it up in the database, and if everything is OK, it displays the corresponding file.

 

This provides maximum convenience for your customers (it's just like a normal file link), but at the same time you can control the file access. You can make the links expire after a while, you can manually disable them in case they're leaked etc.

That also helps avoid the situation where a user with a valid link tries to manipulate values in their link to find another pdf.

[DeX]

Great ideas, guys, I'm going to do this for sure, the other added benefit of your suggestions is that Google can no longer spider the PDF and show them to anyone Googling a name. I think I already avoided this with my robots.txt but it has been a problem in the past.

 

I think I will still move the PDF folder outside the web directory just to make it easier to roll out updates, I no longer have to skip the PDF folder when moving all folders into production. I can just use a symlink to get the same functionality or just serve it up with PHP like someone suggested.

[requinix]

Great ideas, guys, I'm going to do this for sure, the other added benefit of your suggestions is that Google can no longer spider the PDF and show them to anyone Googling a name.

If you're saying that by moving the PDFs outside the web root then that's not entirely true. What matters is whether Google can find a URL (and it's very good at that*) and whether it can get the contents of the URL. Simply hiding the PDFs behind a PHP script isn't enough - it needs to require authentication too.

 

I think I already avoided this with my robots.txt but it has been a problem in the past.

It'll help you with the good bots, but you won't be protected from the bad bots who don't respect robots.txt.

 

 

* If you use Google Talk, share a link with someone over it, and they click the link, Google will pick it up. At work, we've had them discover development sites that way - they weren't supposed to be publicly accessible but they were misconfigured. The sites got indexed. After applying a robots.txt to our environments and firewalling the boxes, it took a few weeks for the index to lose the sites.