> 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
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
