Re: Re: RFC: Implementing a core anti-XSS escaping class
| From: | Michael Shadle | Date: | Wed, 19 Sep 2012 16:06:43 +0000 |
| Subject: | Re: Re: RFC: Implementing a core anti-XSS escaping class | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63143@lists.php.net to get a copy of this message | ||
> 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