Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:63144 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54743 invoked from network); 19 Sep 2012 16:09:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Sep 2012 16:09:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.133 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 64.22.89.133 oxmail.registrar-servers.com Received: from [64.22.89.133] ([64.22.89.133:39536] helo=oxmail.registrar-servers.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 80/D6-15057-D3EE9505 for ; Wed, 19 Sep 2012 12:09:33 -0400 Received: from [192.168.0.200] (5ad4bfa1.bb.sky.com [90.212.191.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oxmail.registrar-servers.com (Postfix) with ESMTPSA id DFA4C758083; Wed, 19 Sep 2012 12:09:29 -0400 (EDT) Message-ID: <5059EE09.1010802@ajf.me> Date: Wed, 19 Sep 2012 17:08:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Michael Shadle CC: Leigh , "internals@lists.php.net" References: <0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com> <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com> In-Reply-To: <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class From: ajf@ajf.me (Andrew Faulds) On 19/09/12 17:06, Michael Shadle wrote: >> It feels like this is just using classes for the sake of using >> classes, adding an unnecessary layer of complexity (and discussion) >> for no real reason except that is the RFC authors preference. > +1 > > First the discussion was filtering vs escaping. Now it is about how to implement it as a class etc. > > I don't understand why people have any issue with it being a core procedural function. You can call that from your OO code just fine. Just like any other core procedural function. Yes, but typing the encoding every time is cumbersome. Or, if you don't want to set it every time, you'd have to set it globally. Then, you forgot to change it back somewhere when you're dealing with multiple encodings, and it all goes wrong. > There is no reason it has to be OO. OO has to call procedural functions already (string functions, array functions, curl, json, etc etc); but us procedural purists don't have to call OO methods and classes if we don't need to (except now some of the DateTime IIRC which bugs me :p) > > Anyway how hard is it to use something akin to the filter functions? That's what constants/flags are for. > > Call it str_escape(string, flags optional, encoding optional) and be done with it. Since it won't be useful to have escape_var or escape_input type of differentiation and this seems like it could just fit under the string family of functions (I am a fan of namespaced functions by prefix) > > After that it seems like the discussion would be: > 1) do we even need encoding or is UTF8 just fine UTF8-only is certainly not just fine. > 2) what are the flags to be defined for different escaping methods > $.02 > -- Andrew Faulds http://ajf.me/