Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95121
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error)
To: internals@lists.php.net
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>
 <E1.B7.55605.EC1EEA75@pb1.pair.com>
 <CADyq6sKZRBvYFtqyKYVYM4iUEx+2OuUJvHeP1jznM56k3+hznA@mail.gmail.com>
Message-ID: <d892f80d-5b81-4b17-ca5d-cc43ebc04c54@lsces.co.uk>
Date: Sat, 13 Aug 2016 18:02:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <CADyq6sKZRBvYFtqyKYVYM4iUEx+2OuUJvHeP1jznM56k3+hznA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Simple variable handling.
From: lester@lsces.co.uk (Lester Caine)

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