Sorry Richard if you received this twice.
Okay let me get this straight:
You protect your includes by making sure that they have a protected
string defined?
You pass JS and CSS through PHP, and output a 404 unless they've got a
HTTP_REFERER variable set to whatever you want it to be?
I guess it may have some merit, but personally it seems like you're
going from Hong Kong to Shanghi through Paris.
Your first suggestion (protecting php includes) has merit if you're
designing a package that people are going to download, and you have
minimal control over how they install it. If you're trying to stop
people from reading your PHP code however you're misguided if you
think there is any solid method other than placing it outside your
webtree.
The Browser needs access to your .js files and .css files. It's not
going to take long to figure out that the server checks the
HTTP_REFERER, and once you've done that, all you have to do is
something put something like the following into the address bar:
javascript:void(document.write("<a
href='http://www.example.com/stylesheet.css'>ss</a>"))
Right-click and "Save Link As"(Firefox), or "Save Target As"(MSIE),
and they get a dialog box asking them where they want to save your
css/js file to.
At least with your first suggestion(protecting php scripts) you
actually get to Shanghi. With your second one, you go from Hong Kong,
to Paris, and back to Hong Kong.
And before you ask, no I'm not Chineese.
On 5/11/05, Richard Lynch <ceo@xxxxxxxxx> wrote:
> You could do all this...
>
> Or you could just move the files outside your web tree and change your
> include path. [shrug]
>
> On Tue, May 10, 2005 9:03 pm, Kit DeKat said:
> > $const = get_defined_constants();
> > if( !isset($const["SOME_CONSTANT"]) ||
> > ($const["SOME_CONSTANT"] != 'secret_string') )
>
> http://php.net/defined
> would be more clear...
>
> > You will take a performance hit for adding the parser to more pages, but
>
> You'd have to benchmark on your own system to be certain, but others have
> reported in the distant past that it's a 5-10% performance hit to pass all
> .htm files through PHP.
>
> Presumably that would apply for .css and .js as well.
>
> I use .htm and pass through PHP, because I find it frees me up to build a
> better site with more cool PHP snippets/features without having to
> maintain old URLs in a change from .htm to .php YMMV.
>
> > 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...
>
> If an end user wants to read your CSS or JS bad enough, they can get it.
>
> Nor is this really a problem.
>
> 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.
>
> 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.
>
> --
> Like Music?
> http://l-i-e.com/artists.htm
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
