Performance-oriented way to protect files on PHP level?

Question

I am looking for some input on something I have been thinking about for a long time. It is a very general problem, maybe there are solutions out there I haven\'t thought of

Answer 1

Anything sensitive should be stored in a secure area like you suggested.

if your website is located at /var/www/public_html

You put the assets outside the web accessible area in /var/www/assets PHP can call for a download or you can feed the files through PHP depending on your need.

If you kept the HTML in the CMS DB, that would leave only non-sensitive images & CSS.

If you absolutely have to turn on and off all access to all materials, I think your best bet might be symlinks. Keep -everything- in a non-web-accessible area, and sym link each folder of assets into the web area. This way, if you need to lock people out completely, just remove the symlink rather than removing all files.

I don't like it, but it is the only thing I can think of that fits your crtieria.

Answer 2

EDIT: How about a hybrid for the administrative interface? In the ACP you could access via the PHP method to, basically, send all file requests to the PHP authing file, but for public, you can use HTTP AUTH/htaccess to determine the availability of the result. this gives you the performance on the public side, but the protection on the ACP side.

OLD MESSAGE:

.htaccess is compatible with most Apache and IIS<7 environments (using various ISAPI modules) when using mod_rewrite type operations. The only exception is IIS7 + the new Rewrite module which uses the web.config file. HOWEVER, I'd be willing to be that you could efficiently generate/alter the web.config file for this instance instead of using .htaccess.

Given that, you could set up redirects using the rewrite method and redirect to your custom 404 Page (that hopefully sends the proper 404 header). It is not 100% appropriate because the actual asset should be the one giving a 403 header, but... it works.

This is the route I would go unless you want to properly create HTTP AUTH setups for every server platform. Plus, if you do it right, you could make your system extendable to allow other types in the future by you or your users (including a php based option if they wanted to do it).