On 02/09/2016 11:11, Yasuo Ohgaki wrote:
Taking care of tampered data by business logic will reduce both readability and maintainability. And more importantly, make code less secure because programmers tend to focus on logic in model, not input data validations.
This certainly makes sense. I guess the challenge is that in order to know if data has been tampered, you need to have some knowledge of the expected format. That expectation depends on what data you're expecting, which depends - ultimately - on the domain objects being modelled.
More specifically, though, it depends on the interaction design - in an HTML context, the forms being presented. So the validation needs knowledge of the form controls - e.g. if a select box was shown, and the value is not from the known list of options, the input has been tampered with.
If that's the case, the logical place to build the validation is into a form builder. At which point you've probably got a complex architecture in userland, and filter_* functions are unlikely to be a natural fit.
If somebody's *not* using a library to build the form (e.g. they're laying out the HTML by hand), are they likely to set up the complex validation settings needed by the filter_* functions?
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
