Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95170
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender)
To: Marco Pivetta <ocramius@gmail.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>
References: <CAGa2bXarw2jTj0yhXpywWNQOJLR2pdhfaqSdwj_btT2giEL15Q@mail.gmail.com>
 <CAGa2bXadVagTwBzEym9PZROmXu3SKxg=huCAQNK3k1-jZeG_pg@mail.gmail.com>
 <CAGa2bXY-vmEgEFrE0OxQPSx=FKHeHdCayrDXxtTkHUVaJbV+-A@mail.gmail.com>
 <CA+kxMuRiOBQpmTeKqNyV8rX0GKCLrYixi--y5TcYUkdqpT746w@mail.gmail.com>
 <CAGa2bXa78fkZw8gtepmBDu+VDwHW_WiDDv65=zzgLTFqYxF+DA@mail.gmail.com>
 <CADyq6s+Y-OeKEyMus5s7xp9MqY7Fq7udqd5BRwtyGXbYCY1Uag@mail.gmail.com>
 <CADyq6sJuHCrLOoL22MWHv+cfrQQx9z=avswCpDVmnuyBCAchsA@mail.gmail.com>
 <CADyq6sKs=e_1Pc_CCLuThsU-qsvRseQcpx=sWKB_uhWsg=aRmQ@mail.gmail.com>
Cc: Dan Ackroyd <danack@basereality.com>,
 PHP Internals List <internals@lists.php.net>
Message-ID: <7795ca21-bd70-fe65-9519-af95fdfee33f@gmail.com>
Date: Sun, 14 Aug 2016 22:17:07 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CADyq6sKs=e_1Pc_CCLuThsU-qsvRseQcpx=sWKB_uhWsg=aRmQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter
 module
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> It seems there is misunderstanding.
> These new functions are intended for "secure coding input validation" that
> should never fail. It means something unexpected in input data that
> cannot/shouldn't keep program running. Why do you need to parse
> message?

I think the problem here is as follows: assume you accept use input. You
want it to conform to some set of rules. If it does not, you may want to
inform the user that the input is wrong, in an informative way. Now, if
you say these functions "should never fail", it implies that before
them, there would be other functions filtering user input (because user
input could always violate whatever rules you'd have) - and then the
question is, would you really want *two* sets of validators? You'd
probably want one.
Now, when you have one, you probably want it to validate the data and
return some information that would be useful for informing the user what
has gone wrong. That seems to be the issue here.
I do think having strong input validation is a good thing. However, we'd
also need to have them in a way that would make them useful in above
scenario - otherwise people would avoid them because they fail "too
hard" and the app does not retain enough control over the outcome.

> There is misunderstanding on this.
> As I wrote explicitly in the RFC, input validation and user input
> mistakes must be handled differently.
> 
> "The input validation (or think it as assertion or requirement) error"
> that this RFC is dealing, is should never happen conditions (or think
> it as contract should never fail).

This is what I'm not sure I understand - when this approach would be
used? I.e. if I get data from the user, I surely can not claim I can
impose any conditions on the data that would never fail. Is it assumed
I'd pre-filter the data before passing it to this filter?

> The point of having the input validation is accept only inputs that
> program expects and can work correctly. Accepting unexpected
> data that program cannot work correctly is pointless.

Well, that depends on what you mean by "accepting". The program should
exhibit sane behavior (i.e., useful error message, not whitescreen or
something like that) on bad input. That behavior can be different -
i.e., if you are given wrong password, you shouldn't be too helpful and
say "this password is wrong, the right password is this: ...." (you'd
laugh but there *was* a real application doing this, no, I have no idea
what the developers were thinking :) but at least you could say
"authentication details are wrong".

> Don't misunderstood me. I'm not saying "You should reject user input
> mistakes".
> "User input mistakes" and "input validation error" is totally different
> error.

Here, again, I am not sure I understand the difference.
-- 
Stas Malyshev
smalyshev@gmail.com