Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95122
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADyq6sLXYxOA7f1X_Cf-oaOHbUaqcoDyKn3B01f6zLbSZp7Fjg@mail.gmail.com>
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>
 <d892f80d-5b81-4b17-ca5d-cc43ebc04c54@lsces.co.uk> <CADyq6sJgVD3-Y+84kvJ_GuBL4zWK9Ev+GE64bMzoBkDOa+Ubyg@mail.gmail.com>
 <CADyq6sLXYxOA7f1X_Cf-oaOHbUaqcoDyKn3B01f6zLbSZp7Fjg@mail.gmail.com>
Date: Sat, 13 Aug 2016 19:28:53 +0200
Message-ID: <CADyq6sK8M3_xhddeGpzj64RZcZN-4FLFBBaEFG1C4mHnO4Fa_g@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb1ea8a70482c0539f75554
Subject: Re: [PHP-DEV] Simple variable handling.
From: ocramius@gmail.com (Marco Pivetta)

--e89a8fb1ea8a70482c0539f75554
Content-Type: text/plain; charset=UTF-8

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" <lester@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

--e89a8fb1ea8a70482c0539f75554--