Stas, Encoding or Escaping is universally used in association with output in the standard security language. I really don't see anything to debate here. I take your point that the escaper could be implemented as a series of filters. I think that would be the wrong move because nobody will actually use the suggested function prototype in a template where typing is at a premium and where filters are simply not synonymous with output escaping. Few programmers would use the phrase filter in this context, few will endure a long winded filter function prototype without rewrapping it back to brevity, and how would character encoding be dealt with in this?
Reusing an existing API that obviously doesn't fit the suggested RFC characteristics is at least as bad as creating a new narrower API that maintains brevity by being specialised. Paddy On Tue, Sep 18, 2012 at 6:55 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> No, he's not. Filtering and escaping are two very significant concepts >> in security. Just because PHP implemented some escaping concepts into >> the filter function does not mean that the concerns are co-related. > > Again, you are taking very narrow definition of filterting, which is not > justified by anything but your very narrow use case, and try to present > it as if this is the only meaning filtering has (despite numerous > examples of using of filters in more generic sense) and that because of > this we need to duplicate APIs we already have, just because you can use > them in different context. To me, it makes no sense - you can apply data > filtering anywhere. If for your specific purpose of explaining how to > make better security architecture you choose to define "filtering" and > "escaping" as narrow distinct concepts, this is fine. This does not mean > that we can not use existing filter extension - with already implemented > methods doing exactly what is needed to be done - because they are to be > used in context which you call "escaping". > >> Actually, that's the basic definition of a filter (from a security >> context). Just because people implemented other things and called them >> filters does not make them filters in the context of this discussion. > > It is your definition of a filter, which is in no way "basic" or universal. > >> The other point that you seem to be missing is that filtering is generic >> for an application. You would apply the same filters for content that >> came in from an HTTP post as content that came in from a JSON API call. >> The data is what's filtered for your application. > > Again, nowhere it is said that you can not apply different filters to > different data or different context. Again, you narrow down definition > of filtering, to which I see no purpose unless you seek to arrive at > pre-determined conclusion that we need to duplicate APIs because it's > called "filter". > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
