Re: protect your CSS files, and possibly other extenstions as well...

Richard Lynch wrote:

You could do all this... Or you could just move the files outside your web tree and change your include path. [shrug] This is probably true, but I was thinking of a virtual hosting environment where its easier to maintain the code when its all in a sub-directory named by the address. But even then I guess you can make the document root one below the virtual host root and then place includes next to the document root to keep them grouped together, yet seperated.

if( !isset( $_SERVER["HTTP_REFERER"]) ||

       !strpos($_SERVER["HTTP_REFERER"],$_SERVER["SERVER_NAME"]) )
   

I don't think you can count on HTTP_REFERER to be set by browsers. It's not required by the HTTP spec, as I understand it. Plus, it seems to me like you are asking for trouble between www.example.com and example.com if they surf to www. but your developer/designer only uses 'example.com' I also would wonder if this will scale up to server farms? Maybe the REFERER/SERVER_NAME stuff is all hunky-dory consistent there... I tested the HTTP_REFERER in both IE v6 and FireFox v1 and the code is working. I dont have an IE v5.x to test on or I would've verified that as well. the SERVER_NAME string will be equal to www.example.com or just example.com, whichever was used to access the site -- it is pulled from between the http:// and the next / so it will allow access to only a self referring server call.

As for server farms, the SERVRE_NAME part will have to be modified to include every allowable server that can refer to it.

If an end user wants to read your CSS or JS bad enough, they can get it. Nor is this really a problem. There have been incidents in the past when another website stripped an artists site entirely; html, css, js, images, everything. This code will prevent css and js from being directly downloaded from a web browser. This will work as long as you dont have another service accessing the directories, such as ftp that bypasses the web server parsing routine.

The following two methods for linking to stylesheets was used in testing: <link rel="stylesheet" href="/styles.css" type="text/css"> and <style type="text/css"> @import('http://<?=$_SERVER_NAME?>/styles.css'); </style>

You definitely do *NOT* want them able to surf to non-entry (ie, 'include'd) files! Your developers (you) almost certainly spent zero time wondering "what if" the user did that, and them executing your .php/.inc/.inc.php file out of context could wreak havoc. That is the whole intention of this exercise, to prevent direct user access to included

files both templated and configuration files. As mentioned earlier, my intention was on virtual host directories that keep all the files under on roof. This method for hiding php scripts is already used widely in many php-portal kits that keep everything in one directory for ease of install for end-users. My ammendum for css and js files prevents nosey ripoffs away from an original designers work. They spent a lot of time in these designs and dont want random joe to just copy it for self-serving purposes. Even if they have all the html, they will have to spend some time trying to figure out the styles and javascript calls to match your sites look and feel. I dont think the majority of the ripoff artists will spend that time, and they will move on to someone else.

There are many "solutions" for this -- But to me, moving the files out of the web tree and setting include_path makes the most sense as the safest. There's *NO* *WAY* you're gonna screw up your httpd.conf or .htaccess files and make the files not in the web tree suddenly accessible. It's not like setting include_path is rocket science once you figure out that this is EXACTLY what that is for. Just my opinion. As mention earlier I will look into the shuffling of directories and modification of the include_path

for hiding included files and see what modifications are needed for the code then.