Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95782 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 2815 invoked from network); 8 Sep 2016 10:34:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Sep 2016 10:34:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-lists@koalephant.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php-lists@koalephant.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain koalephant.com designates 206.123.115.54 as permitted sender) X-PHP-List-Original-Sender: php-lists@koalephant.com X-Host-Fingerprint: 206.123.115.54 mail1.25mail.st Received: from [206.123.115.54] ([206.123.115.54:59839] helo=mail1.25mail.st) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D9/45-36123-DAE31D75 for ; Thu, 08 Sep 2016 06:34:24 -0400 Received: from [10.0.1.23] (unknown [183.89.106.123]) by mail1.25mail.st (Postfix) with ESMTPSA id 4C22A6056B for ; Thu, 8 Sep 2016 10:34:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) In-Reply-To: Date: Thu, 8 Sep 2016 17:34:08 +0700 Content-Transfer-Encoding: quoted-printable Message-ID: <8E15A146-F5B6-41AA-8177-4DAA5ACB35C4@koalephant.com> References: <232F1604-2211-4351-B830-EDC958A25D6D@strojny.net> <2de35db0-9974-cc96-83dd-3d2dbd48f7f8@lsces.co.uk> <5b72e9da-068a-bc79-82c2-f36f723f42bb@gmail.com> To: "internals@lists.php.net" X-Mailer: Apple Mail (2.3124) Subject: Re: [PHP-DEV] [RFC][VOTE] Add validation functions to filter module From: php-lists@koalephant.com (Stephen Reay) So, I=E2=80=99m 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 = wrote: >=20 > On 08/09/2016 09:28, Yasuo Ohgaki wrote: >> This might be the largest difference. >>=20 >> To make something secure than it is now, adding additional security >> layer is effective, not single location/code. >=20 > 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? >=20 >=20 >> Suppose we have validation module. You are suggesting something like >>=20 >> $int =3D validate_int($var, $min, $max); >> $bool =3D 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 =3D validate_string($var, $min_len, $max_len); >> $str =3D validate_string_encoding($var, $encoding); >> $str =3D validate_string_chars($var, $allowed_chars); >> $str =3D validate_string_regex($var, $regex); >> $str =3D validate_string_degit($var, $min_len, $max_len); >> $str =3D validate_string_callback($var, $callback); >=20 > No, I'm suggesting something like: >=20 > 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 > } >=20 > 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. >=20 >=20 >> [...] Rule reuse and centralizing validation rule is easy. >=20 > The language provides us plenty of ways to reuse code. For instance: >=20 > function validate_my_field($var) { > return > validate_int($var, $min, $max) > && validate_bool($var, $allowed_bool_types) > // etc > } >=20 >=20 > Regards, > --=20 > Rowan Collins > [IMSoP] >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20