Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95258 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 72144 invoked from network); 17 Aug 2016 09:00:18 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Aug 2016 09:00:18 -0000 X-Host-Fingerprint: 80.177.120.119 marston-home.demon.co.uk Received: from [80.177.120.119] ([80.177.120.119:1602] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F1/44-45465-D9724B75 for ; Wed, 17 Aug 2016 05:00:13 -0400 Message-ID: To: internals@lists.php.net References: <90.51.36656.0C0A1B75@pb1.pair.com> In-Reply-To: Date: Wed, 17 Aug 2016 10:00:06 +0100 Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Newsreader: Microsoft Windows Live Mail 16.4.3564.1216 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3564.1216 X-Posted-By: 80.177.120.119 Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module From: TonyMarston@hotmail.com ("Tony Marston") "Yasuo Ohgaki" wrote in message news:CAGa2bXZjgggpJsVXQMDJMqvnpTBUCAhazBwjRtBiPsb-BohQnQ@mail.gmail.com... > >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. If your RFC is about preventing attacks then it should be labelled as such. Input validation is a totally separate issue. -- Tony Marston >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 >wrote: >> "Dan Ackroyd" wrote in message >> news:CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com... >>> >>> >>> Hi Yasuo, >>> >>> On 15 August 2016 at 01:53, Yasuo Ohgaki 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% >