A "NI" or "Email address" concept is only a string at low level.
It is well known/accepted that such concepts should be turned into simple objects instead, so that you can actually use type-signatures to type-hint against NI/Email. This avoids having to re-validat e for data-integrity and correctness of a value at every layer of your architecture. Add `__toString` to them and they even behave like they did before (strings). On 13 Aug 2016 19:02, "Lester Caine" <les...@lsces.co.uk> wrote: On 13/08/16 14:43, Marco Pivetta wrote: > It receives a value (nested, if necessary) and tells us if it is valid or > not, plus why (as a set of strings, usually). > > This is validation. Please do use separate terminology if you mean: > * "frontend (client-side) validation" > * "frontend (server-side) validation" > * "domain validation" > > Even more specific if you are going with something different, please. Not quite sure what you are referring to by 'domain validation' all *I* am talking about is the process of obtaining a valid set of data to store in a database. Nothing more. That is a set of variables with a little more complex rules than the simple 'int' or 'string' type checking that has caused so much trouble. There are many useful well defined strings such as email address, National Insurance Number Bank sort code and so on which have well defined rules against which to validate the data supplied. An NI Number is a fixed well defined string that does not need escaping when displayed, but may in some cases need masking if the client user does not have full access. Most systems will actually be used by real people who expect the client side to be fast, so passing those rules client side is part of a process to handle variables. The same rules are used server side to validate the dataset and when there are no morons around the server side should have to do little more than rubber stamp the various variables in the post data. Additional checks are normally added server side such as if an NI number already exists, or a valid postcode has been supplied. Something which could also be actioned via an AJAX check. Nowadays even inside PHP the gap between client and server is somewhat woolly ? and this is where access on a variable by variable basis to the rules is essential. But we do have morons around who take pleasure in trying to make life difficult for everybody else. They will capitalise on any known weakness to try and mess sites up. That the validation process has to be robust enough to cope with this sort of activity IS a different problem, but with a robust variable based validation, injections should be difficult to push through and apart from the previous discussions on being able to store examples of malicious code while avoiding it also being able to be activated, my preferred workflow ensures that validation includes elimination of any potentially malicious code. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
