Richard Lynch wrote:
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.You could do all this...
Or you could just move the files outside your web tree and change your
include path. [shrug]
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.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...
As for server farms, the SERVRE_NAME part will have to be modified to include every allowable server that can refer to it.
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.If an end user wants to read your CSS or JS bad enough, they can get it.
Nor is this really a problem.
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>That is the whole intention of this exercise, to prevent direct user access to includedYou 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.
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.
As mention earlier I will look into the shuffling of directories and modification of the include_pathThere 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.
for hiding included files and see what modifications are needed for the code then.
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
