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.
--------------------------
Some anti-virus/firewall type software does not allow the browser to
send the referrer - it cannot be relied upon, which is Richard's point.
--------------------------
>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>
--------------------
The css and js files will still be transmitted to the client, so they
can be retrieved from temporary internet files or wherever the browser
stores them. I don't see how your method will prevent anyone from
accessing these files - they need to be on the client for your page to
display correctly.
--------------------
>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.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Gamma Global : Suppliers of HPCompaq, IBM, Acer, EPI, APC, Cyclades, D-Link, Cisco, Sun Microsystems, 3Com
GAMMA GLOBAL (UK) LTD IS A RECOGNISED 'INVESTOR IN PEOPLE' AND AN 'ISO 9001 2000' REGISTERED COMPANY
**********************************************************************
CONFIDENTIALITY NOTICE:
This Email is confidential and may also be privileged. If you are not the
intended recipient, please notify the sender IMMEDIATELY; you should not
copy the email or use it for any purpose or disclose its contents to any
other person.
GENERAL STATEMENT:
Any statements made, or intentions expressed in this communication may not
necessarily reflect the view of Gamma Global (UK) Ltd. Be advised that no content
herein may be held binding upon Gamma Global (UK) Ltd or any associated company
unless confirmed by the issuance of a formal contractual document or
Purchase Order, subject to our Terms and Conditions available from http://www.gammaglobal.com
E&OE
**********************************************************************
**********************************************************************
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
