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 <les...@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
