Hi Lester,
On Wed, Feb 25, 2015 at 6:52 PM, Lester Caine <les...@lsces.co.uk> wrote:
> Totally understand what you are trying to do, and if the users you are
> trying to protect actually downloaded PHP direct from the PHP site it
> may stand a chance of actually doing that, but it's adding restrictions
> that WILL break other distributions so either they have to re-work what
> they do, or switch it off anyway. The people you are trying to protect
> are going to be downloading a distribution that may well be using
> 'obvious mistakes' such as .inc or .php5 in addition to .php
>
> There have been attempts in the past to make 'script only' files and and
> these same sort of restrictions, but the fallout did prove more of a
> problem. Example ... one of the legacy sites I just had to move stopped
> doing any of the navigation stuff and would not send a contact email.
> Was working fine previously ... but when I actually started looking at
> the code strangely the pages were all .html ... yep ... a complex site
> with lots of content which had originally been hand coded and at some
> point a few little bits of php had been added in. My nginx setup had
> disabled processing .html pages so broken site. I don't want to rename
> all of the files to .php ... I don't need to ... so I've created a
> php-fpm for .html only and we are working again. Only a few hours wasted
> but the sort of thing we have to be able to cope with!
>
I understand people do all kinds of things.
Therefore, I'm allowing
ini_set('zend.script_extension', ''); // Disable protections at all.
It's users choice if they use systematically secure configuration or not.
However, providing systematically secure method/configuration is our
responsibility. IMHO.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
