Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95246
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <90.51.36656.0C0A1B75@pb1.pair.com>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXadVagTwBzEym9PZROmXu3SKxg=huCAQNK3k1-jZeG_pg@mail.gmail.com>
 <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
 <CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com> <90.51.36656.0C0A1B75@pb1.pair.com>
Date: Wed, 17 Aug 2016 08:43:13 +0900
Message-ID: <CAGa2bXZjgggpJsVXQMDJMqvnpTBUCAhazBwjRtBiPsb-BohQnQ@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Tony,

Allow me to top post.

"The input validation" is not for legitimate users, but for attackers.
You shouldn't help attackers by explaining what/how wrong in attackers' inputs.

I've added discussion "Input validation and User input mistake
handling difference"
https://wiki.php.net/rfc/add_validate_functions_to_filter#input_validation_and_user_input_mistake_handling_difference

Please refer to the section for distinction.

BTW, the input validation that I'm proposing here is
required/recommended feature by ISO 27000/ISMS. Why shouldn't PHP
provide features that is needed to implement ISO 27000/ISMS
requirements?

On Mon, Aug 15, 2016 at 8:00 PM, Tony Marston <TonyMarston@hotmail.com> wrote:
> "Dan Ackroyd"  wrote in message
> news:CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com...
>>
>>
>> Hi Yasuo,
>>
>> On 15 August 2016 at 01:53, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>>> One more usual request.
>>> Please describe reason(s) why you object proposal.
>>
>>
>>
>> I'm not entirely sure why you ask for reasons when people vote no. The
>> reasons are almost always the same as the reasons given before the
>> voting starts.
>>
>> But for posterity:
>>
>> i) Validation error messages need to specify what is wrong.....which
>> is bespoke to the application. Which is a reason why validation code
>> belongs in userland.
>
>
> I agree 100%
>
>> ii) Validation error message need to be in the correct language for an
>> application. It is not a good approach for people to be trying to
>> match strings emitted by internal code and trying to convert them to
>> the correct language.
>
>
> I agree 100%
>
>> iii) The argument that it needs to be fast could be applied to
>> anything and everything, and so is bogus. The RFC doesn't even show
>> that userland implementations are slow enought to be a concern.
>>
>> iv) The RFC makes an assumption that programs should exit when validation
>> fails.
>>
>> "Input data validation should accept only valid and possible inputs.
>> If not, reject it and terminate program."
>
>
> I DISagree 100%. Validation errors should NEVER terminate the program, they
> should continue by displaying all the error messages to the user so that
> he/she can correct his/her mistake and try the operation again.
>
>> and the code example:
>>
>>> catch (FilterValidateException $e) {
>>>    var_dump($e->getMessage());
>>>    die('Invalid input detected!'); // Should terminate execution when
>>> input validation fails
>>> }
>>
>>
>> This assumption is bogus.
>>
>> Any program that accepts data from users should provide useful error
>> messages when the data is wrong with someting as simple as a string
>> being too long.
>
>
> I agree 100%
>
>> v) I don't like the current filter functions, and recommend people
>> avoid using them. Adding to them with an even harder to use API is the
>> wrong way to go.
>
>
> I agree 100%

--
Yasuo Ohgaki
yohgaki@ohgaki.net