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.coll...@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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
