Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95085
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <ab77510e-bcd9-fdee-5a66-dcba2baba0b4@lsces.co.uk>
References: <10fbcb03-5de8-4d9a-da1c-7e2bf77937cb@lsces.co.uk>
 <CAEYWF=4kkvmp8TCmRhdhzzM-sWpk+-sYE7u2eP1Jf3NkshFiJA@mail.gmail.com>
 <CABdc3WqYeoXoHL-E4adjoZTVr1bs1CHfRaDmoqtmpGW7yREmUA@mail.gmail.com>
 <c76f0716-4881-4aae-2fbd-f1af70fd6114@lsces.co.uk> <CANUQDCjaXeJsCAjyE+q-UhXCFjexwRYWLKzMfwRQVDaEwVbLog@mail.gmail.com>
 <d67a6ee8-4fbe-9583-3bac-d2e98298663f@lsces.co.uk> <5657afc7-7569-5fc4-4a5a-27ed786c4fa5@gmail.com>
 <0825c173-5cb4-7f65-cf34-b45ca30919a3@lsces.co.uk> <8646c3ad-b929-cb0b-bad4-52a0a7160d16@gmail.com>
 <11ce571b-964b-5a3e-9f2f-3f69a8bc20b4@lsces.co.uk> <7d9db8d5-ae7a-4123-14f4-f76fb6d764c5@gmail.com>
 <a25c0473-aa5f-7a1a-d1c9-0c8eebfd1188@lsces.co.uk> <bbe11a4d-26ce-e140-52d0-71d7afbffbba@gmx.de>
 <1e14c4b9-65ce-4742-589f-19fe9290be0f@lsces.co.uk> <CAEU6NAdh42oxiDRUJRVekcEAadiqsQYXYQUDE7XOg3WLQMsXPg@mail.gmail.com>
 <ab77510e-bcd9-fdee-5a66-dcba2baba0b4@lsces.co.uk>
Date: Fri, 12 Aug 2016 19:51:33 +0900
Message-ID: <CAGa2bXYi3HGGMNz6nMZE5gAAVOFyb5F2xKAcEP5RKYOZzUidkg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Simple variable handling.
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Lester,

On Fri, Aug 12, 2016 at 7:13 PM, Lester Caine <lester@lsces.co.uk> wrote:
>> That said, I generally think that built-in methods that accept Callables
>> are a great way to go. It encourages reuse through modular composition -
>> and could likely be a neater way around the throw exception/return error
>> code issue. It's obviously doable from userland, but could probably be
>> improved if implemented in the language.
>
> It was the fact that Yasuo was adding these rules into his array
> validation stuff that just grates so badly with what is actually needed ...

I think you've mentioned this RFC

https://wiki.php.net/rfc/add_validate_functions_to_filter

In secure coding, input data validation has clear task. It varies what
input data validation should do. i.e. It depends on what sender should
send. The new validation feature in filter module will do the job it
should.

Anyway, input validation spec is simple array. You can do

   $my_date_spec =         array(
                // New filter module allows multiple filters and
options as follows.
                // Array elements are evaluated in order. Non array
spec is evaluated last.
                // Older implementation ignores this kind of spec silently.
                array( // This is evaluated first.
                        'filter'    => FILTER_VALIDATE_STRING,
                        'options'   => array('min_bytes' => 10,
'max_bytes' => 10, 'encoding' => FILTER_STRING_ENCODING_PASS)
                ),
                array(
                        'filter' => FILTER_VALIDATE_REGEXP,
                        'options' => array('regexp' =>
'/^[0-9]{4}-[0-9]{2}-[0-9]{2}$/')
                ),
                array(
                        'filter' => FILTER_VALIDATE_CALLBAK,
                        'options' => array('callback' =>
'check_date_and_raise_exception_for_invalid()'),
                ),
                'filter' => FILTER_UNSAFE_RAW, // Evaluated last. Does
nothing. It's here for an example.
        );


    $get_def_for_an_api = array(
        'date'    => $my_date_spec
    );

   filter_require_var_array($_GET, $get_def_for_an_api);

Input validation definition is manageable. Since it uses a simple
array, it is much more efficient than object based API. i.e. setting
spec via method is a lot slower than simple assignment. There is spec
validation filter_check_definition() function also.

What makes you feel missing some or designed badly?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net