Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100398
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: <f8959d0a-429f-4efc-8682-572680a075fa@lsces.co.uk>
References: <CAGa2bXafM0QgMdCuUfEnNcejHAi208=4tCqbi1APT20Z_jcvuQ@mail.gmail.com>
 <EDA8C042-02B5-4DF9-9D15-176B1DE6587B@gmail.com> <CAGU04m+RtKkPkmzCzFjHvT=pHE9_tVzWuSd6umk2P1U-g8wy_Q@mail.gmail.com>
 <CADyq6s+QpHB2iPb=T=M2NL1aUTS=Uuf07WpQR5j26kFKDCxzpg@mail.gmail.com>
 <0C7F986C-B0BC-4315-98ED-B4FD003B9399@gmail.com> <CAGa2bXa-6kN1yEbnVzbReLX3qH2gVJ5LTmfR31jOp_GwASbrrA@mail.gmail.com>
 <e14c1e6f-4677-6a87-ef30-e3e627c26270@lsces.co.uk> <c08cbbf5-fb27-7c50-3bcc-c89ccfbd6202@rhsoft.net>
 <2a4491b4-e6f5-4297-beec-363f373a93e6@lsces.co.uk> <3f8be7b1-0e59-21c6-4fe8-8299b2c05645@rhsoft.net>
 <6ba62d62-f1ab-9e7b-93f0-a1a9238c47a6@lsces.co.uk> <CAGa2bXYch8UJ70No=UvqtQ79pKbJ1MRtHN0QLk8kCSV+yhMNbg@mail.gmail.com>
 <f8959d0a-429f-4efc-8682-572680a075fa@lsces.co.uk>
Date: Wed, 6 Sep 2017 05:48:19 +0900
Message-ID: <CAGa2bXav1CEZj5vZMSgRs8qs9vp1sz7ydPOFE1VPf_ZReYxhBw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>, Rowan Collins <rowan.collins@gmail.com>, 
	Crocodile <crocodile2u@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a114f890a4fc2db0558775b7c"
Subject: Re: [PHP-DEV] A validator module for PHP7
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114f890a4fc2db0558775b7c
Content-Type: text/plain; charset="UTF-8"

Hi Rowan, Crocodile and Lester,

Rowan,
Thank you for helpful suggestions. I think it may better be named
'validate()'/etc.
Sole reason I named functions as 'valid*()' is name collision.
'validate*()' seems
too common, but users should use namespace to avoid collisions. I'll take
your
suggestions into the module.

Crocodile,
I agree your comment. However, my last filter module improvement RFC
with PoC patch was failed. Upside having new module is we can enforce more
strict validations and can have much simpler/extensible API with cleaner
codes.
(Having both 'filter' and 'validator' in one code is mess)
Since the last attempt was failed, new module would be the next reasonable
attempt.

On Wed, Sep 6, 2017 at 4:39 AM, Lester Caine <lester@lsces.co.uk> wrote:

> On 05/09/17 20:05, Yasuo Ohgaki wrote:
> > There is one principle that developers is better to follow.
> > https://en.wikipedia.org/wiki/Fail-fast
> > If we follow this principle, validation at controller makes sense.
>
Oops. A 'is' should be 'are'.

> Since a large proportion of the data coming in is a result of input into
> a previously generated form, the data can often be validated in terms of
> basic structure before even needing to decide if the data set needs to
> be iterated? If things like 'maximum data size' can be established when
> the form is created, any data set larger than that can simply be killed
> off.
>

> Anyway, thank you for pointer for PDO validation. I didn't notice the
> > project. We may cooperate so that there aren't unnecessary validaiton
> > rule incompatibilities
> I've been pushing the idea of a single method of managing metadata for a
> long time. Most of the 'checking' loading down PHP now still misses the
> point and the database style of rules has been around since long before
> PDO and other abstractions messed it up. A single standard set of rules
> that can be used across the board from variable creation to checking
> data going out to forms and returns coming back and data between
> operations such as database activity. This is NOT 'typing' since that
> lacks the vast majority of checks that a decent validation will handle,
> but the much finer details such as limits and value sets. There is a
> vast discrepancy in how this is handled across databases, but the SQL
> standard does provide a base which databases are slowly evolving towards.
>
>
It's nice to have central input type (Not only data type, but length,
chars, format, range and char encoding, as you mentioned) repository for an
app. That's the reason why I would like to cooperate with other validator
implementation(s) to avoid unnecessary incompatibilities.

(For security perspective, it can be said different types of input
validations is
better because if one failed, another may validate data correctly. However,
managing multiple validation rules is burden. Some people try to validate
inputs with WAF. However, I suggest input validation is better to be
implemented
at web apps, not WAF.
It's a lot easier and maintainable if input validation is done by app. App
developers know what the input should be exactly. In addition, app must
validate inputs regardless of WAF. I'm not saying WAF is useless. WAF
is still useful as network layer protection. I'm saying multiple layer
validations
are recommended, but it can be unmanageable easily unless some trade
off is taken)

I agree that PDO level validation is almost mandatory, especially for
SQLite3.
SQLite3 data type is pseudo type and allows any "characters". e.g. Int type
can store '<script>alert("XSS")</script>', etc.

My validate module allows users to have central input type repository by
simple native PHP array. Array could be stored anywhere users want.
I think it will work as you wish if 'validate' module is compatible with
PDO
validator.

For the time being, I'm not sure what it should be. Data specifications for
database may be stored as additional info in 'validate' spec array, or PDO
validator may simply assume data types specified in 'validate' spec array
should be enforced, and use 'string' data spec as required format,
or 'validate' module may expose API so that PDO validator can use it for
basic PHP data type validation.

Regards,

--
Yasuo Ohgaki

--001a114f890a4fc2db0558775b7c--