results of the PHP6 wishlists

> Simply because it is not the PHP way.

> Thus PHP takes the KISS approach - keep it simple safe.

> Until there is an implementation out there that is in common use, the > question of whether to bundle it or not is rather premature.

> Sorry, do not have time to simplify. This is how I do it: > > function filterRequest($prototype, $action){ > loadPrototype($prototype); > $vars = get_class_vars($prototype); > if ($vars['vigilant'] == FALSE) { > return $_REQUEST; > } > > $filter = getFilter($prototype, $action); > if ($filter == NULL) { > return NULL; > } > if ($filter == TRUE) { > return $_REQUEST; > }

> >> 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:antony@zend.com] > 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. > >