Re: Re: [RFC][VOTE] Add validation functions to filter module
| From: | Tony Marston | Date: | Wed, 17 Aug 2016 09:00:06 +0000 |
| Subject: | Re: Re: [RFC][VOTE] Add validation functions to filter module | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95258@lists.php.net to get a copy of this message | ||
"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 <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% >