> On 15.11.2005 15:06, Roman Ivanov wrote:
>
>> This particular extension treats each input variable individually,
>> which is not desirable in majority of scripts I worked with. Such
>> approach adds unnecessary complexity to the script, and requires to
>> handle each invalid variable separately as well.
Just to weigh in here with a strong preference to *not* implement any
filtering-by-default scheme on all input. As mentioned before every input is
different: email, html, binary data, etc. It seems pretty clear that dealing
with this data is the job of the framework, the cms, or if you want an
extension.
For example, our in-house framework has a library of "validators" (return
true or false) and "normalizers" (input can be changed, not just accepted or
rejected). No user data makes it into a global without being filtered in
this way, and these filters can set global "flags" the programmer can use:
$email = valid_email($_POST['email']);
$message = normailze_text($_POST['message']);
if(count($REPORTS['bad_data'])) {
// Tell user about bad input
}
if(count($REPORTS['changed_data'])) {
// Do we need to let user know we stripped out tags?
// Do we need to notify the webmaster about what got changed?
}
That's just a small part of the system, and the point here isn't that our
way of filtering is best and certainly not the only way, but it does
represent a deliberate choice of how to deal with user data that has lots of
nifty features and works with our system as a whole. Any filtering system
enabled by default would break our system when we distribute it to other
people unless we could disable that system at run-time, and it would
probably end up dodging or deciding business-logic decisions that should be
dealt with by the script.
--
Asher
-----Original Message-----
From: Antony Dovgal [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 15, 2005 5:33 AM
To: Roman Ivanov
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: results of the PHP6 wishlists
On 15.11.2005 15:06, Roman Ivanov wrote:
> This particular extension treats each input variable individually, which
> is not desirable in majority of scripts I worked with. Such approach
> adds unnecessary complexity to the script, and requires to handle each
> invalid variable separately as well. But the real problem is that there
> are many ways of filtering input, and I do not think any of them fits
> all the situations.
Ahha.
So what exactly do you propose?
For example, I have 3 different variables: an email, an integer and a
string.
How do you think I should filter them ?
> >> "Part of the standard API, which is included with PHP and compiles by
> >> default", if you will.
> >
> >
> > So, basically you're objecting against enabling it by default?
> > Why? I really do not see a reason to not include it by default, if it
> > helps to write more secure code.
> > (remember that "enabled by default" means you can disable it in a
> moment).
>
> Well, I think that everything in core distribution is a suggested
> standard. But a language should not, in my opinion, suggest any
> particular structure for the program, unless it's absolutely necessary.
> It's not a major issue, but still...
Sorry, I refuse to understand that.
The language HAS to recommend a way to do something and to allow user to
choose any other way if the recommended one doesn't fit his/her needs.
If there is no a recommended way to do, for example, input filtering, users
would re-invent the wheel every time, which results in square wheels and
engines with security issues discovered every day.
That's the whole point: to provide a fast and comfortable way to filter
data, so the users won't have to do it themselves.
Feel free to offer an improvements, if you have something to offer, but
saying that a standard method of doing something *imposes* a particular
structure is just a nonsense.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
