|
|
Posted by Kit DeKat on 05/11/05 14:58
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.
Navigation:
[Reply to this message]
|