Re: Re: Adding validate_var_array()/validate_input_array() to which version?

Hi Rowan, On Tue, Aug 2, 2016 at 11:37 PM, Rowan Collins <rowan.collins@gmail.com> wrote: > On 01/08/2016 23:12, Yasuo Ohgaki wrote: >> >> Raising Exception would be prefered. >> Any comment raising exception? ExceptionFilterValidate wouldn't >> cause much BC, IMO. > > > I don't follow. Do you mean throwing an exception to the existing > filter-and-continue functions? If so, that would surely break every single > use of those functions. Existing filters currently used are not changed at all. They behave exactly as they are now. If not, it's a bug. Exceptions are raised only when validate_*() functions are used. Input validations should pass almost always. So checking return value from validation functions are not prefered. > > Or do you mean adding a new function which either silently succeeds or > throws an exception? That doesn't sound good to me - an exception shouldn't > be the expected result of something, and invalid input is an expected > condition (just an undesirable one). It's easier to add a throw statement > based on a boolean result than to catch an exception and continue with other > checks. > > I may have misunderstood your question, though. Invalid inputs that violate input validation rules should not happen almost always because input validation is _not_ the same input mistakes by normal users. e.g. typo, user send a little too long password. These mistakes should be handled as input errors/mistakes, not input validation error. Example input validation errors are, - Broken UTF-8 encoding - NUL, etc control chars in string. - Too long or too short string. e.g. Client side validation inputs - JS validated and values set by server programs like <select>/<radio>/etc, 100 chars for username, 1000 chars for password, empty ID for a database record, etc. - Broken number string for a database record ID. - Newline chars in <input>, hash value, etc. - and so on. If there are these kind of inputs, they are intentionally broken inputs. It should result in Exception and program should be _terminated_ script execution after logging attack and sending nicely formatted page that warns attackers, for instance. validate_*() functions should be used to handle above input violations that should never happen under normal condition. Did I understand your concern correctly? I hope explained well. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net