Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19998 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57346 invoked by uid 1010); 15 Nov 2005 13:16:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 57330 invoked from network); 15 Nov 2005 13:16:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Nov 2005 13:16:11 -0000 X-Host-Fingerprint: 206.81.46.34 unknown Received: from ([206.81.46.34:28968] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 8F/F8-07637-B9FD9734 for ; Tue, 15 Nov 2005 08:16:11 -0500 Message-ID: <8F.F8.07637.B9FD9734@pb1.pair.com> To: internals@lists.php.net Date: Tue, 15 Nov 2005 07:06:11 -0500 User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 References: <84.9C.07637.EEB48734@pb1.pair.com> <6A.CC.07637.49C48734@pb1.pair.com> <437932CE.80000@zend.com> <4B.67.07637.41949734@pb1.pair.com> <4379AE54.1080808@zend.com> In-Reply-To: <4379AE54.1080808@zend.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 206.81.46.34 Subject: Re: [PHP-DEV] Re: results of the PHP6 wishlists From: gamblergluck@yahoo.com (Roman Ivanov) Antony Dovgal wrote: > Obviously, no, this won't be the only way to get the data. That's good. >>>> Honestly, I'm not so sure it's a good idea to implement it like PECL >>>> extension does. Filtering individual variables is, in my opinion, a >>>> wrong way to treat user input. >>> >>> You may filter data recursively, so filtering, for example, _POST or >>> _GET would work fine. >> >> Recursion does not solve the problem I'm trying to highlight. >> > Didn't get the problem, sorry. > Could you try to explain it once more? 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. >> "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...