Hi Rowan,

On Tue, Aug 2, 2016 at 11:37 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 01/08/2016 23:12, Yasuo Ohgaki wrote:
>>
>> Raising Exception would be prefered.
>> Any comment raising exception? ExceptionFilterValidate wouldn't
>> cause much BC, IMO.
>
>
> I don't follow. Do you mean throwing an exception to the existing
> filter-and-continue functions? If so, that would surely break every single
> use of those functions.

Existing filters currently used are not changed at all. They behave
exactly as they are now. If not, it's a bug. Exceptions are raised
only when validate_*() functions are used.

Input validations should pass almost always. So checking return value
from validation functions are not prefered.

>
> Or do you mean adding a new function which either silently succeeds or
> throws an exception? That doesn't sound good to me - an exception shouldn't
> be the expected result of something, and invalid input is an expected
> condition (just an undesirable one). It's easier to add a throw statement
> based on a boolean result than to catch an exception and continue with other
> checks.
>
> I may have misunderstood your question, though.

Invalid inputs that violate input validation rules should not happen
almost always because input validation is _not_ the same input
mistakes by normal users. e.g. typo, user send a little too long
password. These mistakes should be handled as input errors/mistakes,
not input validation error.

Example input validation errors are,
 - Broken UTF-8 encoding
 - NUL, etc control chars in string.
 - Too long or too short string. e.g. Client side validation inputs -
JS validated and values set by server programs like
<select>/<radio>/etc, 100 chars for username, 1000 chars for password,
empty ID for a database record, etc.
 - Broken number string for a database record ID.
 - Newline chars in <input>, hash value, etc.
 - and so on.

If there are these kind of inputs, they are intentionally broken
inputs. It should result in Exception and program should be
_terminated_ script execution after logging attack and sending nicely
formatted page that warns attackers, for instance.

validate_*() functions should be used to handle above input violations
that should never happen under normal condition.

Did I understand your concern correctly?
I hope explained well.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to