Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63145
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
Sender: mikegstowe@gmail.com
In-Reply-To: <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com>
References: <CAO1hux8mmUsy4badiNjxTGMubaduD1gkgbw4ZK1Me_MwGwLybA@mail.gmail.com>
 <CALtuQzC4e2Sn_BHinFAPdVrz8Oc_d6wCqTr=AscMChH29NSENw@mail.gmail.com>
 <CAO1hux9+4QK2sVX9+4110ksa9qDpUpfDhFJvyzkXcBHrFoFWvg@mail.gmail.com>
 <0960EAA5-17FF-4E0F-9DDE-BB93D13EA02B@gmail.com> <CAO1hux9t9refYHYnKhY0725MvRm88ab85Ng23LCvnjDJxqQA7g@mail.gmail.com>
 <CALwr1GnjjjMbK8-VkVO57meDAgDn8PSPoWdj2DjYMB7F01dP4Q@mail.gmail.com>
 <CAPwsocGs=5-JfpSSewDRaNC0KaoNF1okBD8-E27fx5U=9f6sgw@mail.gmail.com> <72B22976-6F00-4EF5-88B3-140576CFE4E7@gmail.com>
Date: Wed, 19 Sep 2012 11:11:20 -0500
Message-ID: <CAH8KiX+AmGxnZ_j0KD-1FZ0gLOuYScEx9YURBQWAep_b1T6vTw@mail.gmail.com>
To: Michael Shadle <mike503@gmail.com>
Cc: Leigh <leight@gmail.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=485b390f7a2417301104ca1043da
Subject: Re: [PHP-DEV] Re: RFC: Implementing a core anti-XSS escaping class
From: me@mikestowe.com (Michael Stowe)

--485b390f7a2417301104ca1043da
Content-Type: text/plain; charset=ISO-8859-1

Personally, I would like to see it operate similar to MySQLi, where you
have the convenience of OOP, but can still call a function directly in a
procedural manner.

And I definitely feel like we need encoding.  We can default it to UTF-8 or
to the zend.script_encoding if set, but I think it needs the flexibility to
handle different encoding types as well.




On Wed, Sep 19, 2012 at 11:06 AM, Michael Shadle <mike503@gmail.com> 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.
>
> 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
> 2) what are the flags to be defined for different escaping methods
>
> $.02
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
-----------------------

"My command is this: Love each other as I
have loved you."                         John 15:12

-----------------------

--485b390f7a2417301104ca1043da--