Quoted Text:
In other words, it can only be used to include files at or below the
current directory.
This is counter productive, it is a horrible idea to store include
files within (/below) the document root, if you're going to suggest
strange sweeping changes go the reverse direction, ensure that
> If the very first thing you have to do with a language feature is make
> sure that it doesn't function as designed (which is to execute hostile
> content with local privileges), then clearly the design of that
> feature is wrong.
Or the default value of the configuration setting has been a bad c
Nicolas Bérard Nault writes:
> Correctly using the include clause is the programmer's responsability.
And yet ... I keep going back to the fact that people don't use it
correctly. It's a fact that many people use 'include' incorrectly.
If you say that the people are wrong, then you are asking p
Ron Korving writes:
> Personally, I think include is just fine the way it is.
Google for "php security flaw". Do you think *that's* fine the way it
is?
Clearly, the fact that you can turn this behavior off suggests that
somebody has noticed that it's badly designed. Rather than say, as
some pe
Unknown W. Brackets writes:
> Why not simply disable allow_url_fopen on your server or servers?
Why don't people do that? Obviously ... they don't.
If you have no other answer than "Maybe they don't care about
security, maybe they're stupid, maybe they're native", then may I
suggest that the pr
allow_url_fopen is a PHP_INI_SYSTEM flag, meens you can't change it with
.htaccess
- mike
Unknown W. Brackets wrote:
Why not simply disable allow_url_fopen on your server or servers?
With it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
Why not simply disable allow_url_fopen on your server or servers? With
it set off, you get these errors:
Warning: main() [function.main]: URL file-access is disabled in the
server configuration in .../test.php on line 3
Warning: main(http://www.google.com/) [function.main]: failed to open
s
E_STRICT would be a nice place to leave a warning, but of course, the naive
programmers don't use E_STRICT, so what's the point in that? Personally, I
think include is just fine the way it is. What I could imagine though, is
that the include() function would be enhanced with parameters to
allow/dis
This has been discussed very much long ago. I use variables in include
clauses and always take a very special attention at it. Adding a
warning in E_STRICT does not make any sense either. In no way PHP can
judge if the instruction is needed or not. I, for myself, code in
E_STRICT and don't deserve
Hmm.. If anything, E_STRICT could leave a warning about variables being used
with include/require.. This is the PHP programmers fault clearly.. And the
documentation is exactly the right place.. Your suggestion is pretty much as
stupid as suggesting to forbid ../ in fopen().. There's nothing wro
10 matches
Mail list logo
