Re: [RFC][VOTE] Add validation functions to filter module

So, I’m trying to really understand what the goals of this RFC were/are. Adding a bunch of new functions is IMO the wrong approach to this type of thing. The existing filter_var/filter_input infrastructure works well, if you want to define more rules I would definitely encourage building on/improving that system not adding a bunch of extra functions. I would be greatly in favour of adding some of the additional filter constants suggested (e.g. a FILTER_VALIDATE_STRING with the min/max bytes, or better yet, min/max chars based on current charset). But the new functions whether the originally proposed ones (which seem to just be sugar in place of a userland foreach/array_walk etc with a throw for failed validation) or these more recent suggestions (which seem to be just wrappers around filter_var, no?) make no sense to me. Cheers Stephen > On 8 Sep 2016, at 16:02, Rowan Collins <rowan.collins@gmail.com> wrote: > > On 08/09/2016 09:28, Yasuo Ohgaki wrote: >> This might be the largest difference. >> >> To make something secure than it is now, adding additional security >> layer is effective, not single location/code. > > My instinct is that this extra location would be a maintenance nightmare, as it would need to > keep up with changes elsewhere in the application. In day to day use, what would make this extra > security layer any more likely to be comprehensively maintained than the existing validation layer? > > >> Suppose we have validation module. You are suggesting something like >> >> $int = validate_int($var, $min, $max); >> $bool = validate_bool($var, $allowed_bool_types); >> // i.e. which type of bool 1/0, yes/no, on/off, true/false is allowed >> // This isn't implemented. All of them are valid bools currently. >> $str = validate_string($var, $min_len, $max_len); >> $str = validate_string_encoding($var, $encoding); >> $str = validate_string_chars($var, $allowed_chars); >> $str = validate_string_regex($var, $regex); >> $str = validate_string_degit($var, $min_len, $max_len); >> $str = validate_string_callback($var, $callback); > > No, I'm suggesting something like: > > if ( > ! validate_int($var, $min, $max) > || ! validate_bool($var, $allowed_bool_types) > || ! validate_string($var, $min_len, $max_len) > || ! validate_string_encoding($var, $encoding) > || ! validate_string_chars($var, $allowed_chars) > || ! validate_string_regex($var, $regex) > || ! validate_string_degit($var, $min_len, $max_len) > || ! $callback($var) // Note: no need to wrap this callback, it's just a > boolean-returning function > ) > { > // ERROR > } > > It was a deliberately narrow purpose as an example, but IMHO that's perfectly readable, > and the focus of the module would be on creating a good set of validation rules, rather than > worrying about how they're applied. > > >> [...] Rule reuse and centralizing validation rule is easy. > > The language provides us plenty of ways to reuse code. For instance: > > function validate_my_field($var) { > return > validate_int($var, $min, $max) > && validate_bool($var, $allowed_bool_types) > // etc > } > > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >