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 <tonymars...@hotmail.com> wrote: > "Dan Ackroyd" wrote in message > news:ca+kxmuriobqpmtekqnyv8rx0gkclryixi--y5tcyukdqpt7...@mail.gmail.com... >> >> >> Hi Yasuo, >> >> On 15 August 2016 at 01:53, Yasuo Ohgaki <yohg...@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 yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
