Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95164
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.217.178 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXadVagTwBzEym9PZROmXu3SKxg=huCAQNK3k1-jZeG_pg@mail.gmail.com> <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
Date: Mon, 15 Aug 2016 02:25:15 +0100
Message-ID: <CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module
From: danack@basereality.com (Dan Ackroyd)

Hi Yasuo,

On 15 August 2016 at 01:53, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> One more usual request.
> Please describe reason(s) why you object proposal.


I'm not entirely sure why you ask for reasons when people vote no. The
reasons are almost always the same as the reasons given before the
voting starts.

But for posterity:

i) Validation error messages need to specify what is wrong.....which
is bespoke to the application. Which is a reason why validation code
belongs in userland.

ii) Validation error message need to be in the correct language for an
application. It is not a good approach for people to be trying to
match strings emitted by internal code and trying to convert them to
the correct language.

iii) The argument that it needs to be fast could be applied to
anything and everything, and so is bogus. The RFC doesn't even show
that userland implementations are slow enought to be a concern.

iv) The RFC makes an assumption that programs should exit when validation f=
ails.

"Input data validation should accept only valid and possible inputs.
If not, reject it and terminate program."

and the code example:

> catch (FilterValidateException $e) {
>    var_dump($e->getMessage());
>    die('Invalid input detected!'); // Should terminate execution when inp=
ut validation fails
> }

This assumption is bogus.

Any program that accepts data from users should provide useful error
messages when the data is wrong with someting as simple as a string
being too long.

v) I don't like the current filter functions, and recommend people
avoid using them. Adding to them with an even harder to use API is the
wrong way to go.

cheers
Dan


For the record - these are what my input validation functions look
like. They are bespoke to the application, and provide useful error
messages to the end user when an exception handler catches that
specific exception to a 4xx HTTP response.

function validateOrderAmount($value) : int {
    $count =3D preg_match("/[^0-9]*/", $value);

     if ($count) {
        throw new InvalidOrderAmount("Der Wert muss nur Ziffern enthalten."=
);
     }

    $value =3D intval($value);

    if ($value < 1) {
        throw new InvalidOrderAmount("Der Wert muss eine oder mehrere sein =
.");
    }

    if ($value >=3D MAX_ORDER_AMOUNT) {
        throw new InvalidOrderAmount("Sie k=C3=B6nnen nur
".MAX_ORDER_AMOUNT." auf einmal bestellen ");
    }

    return $value;
}