Re: Re: RFC: Implementing a core anti-XSS escaping class

Hi Michael, >> 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. I have never once expressed a problem with this being a set of procedural function. Not once. The RFC offers some suggested function signatures. So nobody has expressed any issues and nobody has insisted that you be required to use a class or object. > 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) Then please - call the functions as defined in the RFC. > Anyway how hard is it to use something akin to the filter functions? That's what > constants/flags are for. The RFC addresses escaping, not input filtering. Yes, there is a fine line between them but the filter method requires constants, options, and we would then need to later in character encoding. The resulting mutation would be a step backwards in my opinion in guiding users towards the secure use of escaping in applications. > 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 Correct encoding is essential. The entire planet does not use UTF-8, and UTF-8 is not the same as other encodings once you get over the theoretical perfection that should exist and meet the rebels: browsers. Please bear in mind that using the correct encoding has been preached for many many years as a minimum requirement in secure escaping for PHP. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team