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
