Hi, My thinking was an output escaping spec. It is a lot more nuanced than you may initially think as there is context to consider eg you need to escape differently inside a html attribute as you do for straight onto the page, similarly for a js context or css context.
An interface containing a method per context could be one solution, it could also add a general purpose method eg escape($var, $context) al a PSR-3. There is also complexity that may arise from different view implementations in different frameworks. Some use $this->method() to enable "view helpers" in otherwise raw html/php others are more complex and specify their own markup/extensions to php eg twig. I would consider an ideal solution one which in-spite of all these differences allows a dev to intuitively figure out the right thing to do; if their framework of choice uses functions for view helpers they'd be able to guess that calling escape($var, CONTEXT_CSS) would do what they want, equally, if they had some sort of helper implementation $this->escapeCss($var) would work. I'd like to see this PSR go slightly beyond just an interface and create a specification for frameworks to comply to with a minimal set of functionality, naming conventions and a specification which guarantees that a method/function does what you expect. ~C On Tuesday, 4 October 2016 17:40:03 UTC+1, Korvin Szanto wrote: > > Hi Chris, > Are you thinking like a text filter PSR or more of an output management > PSR? It sounds like a single interface with a single method to me: > `FilterInterface::filter($mixed): mixed;`. > > Thanks, > Korvin > > On Tue, Oct 4, 2016 at 7:39 AM Chris Riley <[email protected] > <javascript:>> wrote: > >> Hi, >> >> I think there could be quite some value in producing a spec and set of >> interfaces for consistent output escaping across frameworks. Security is an >> important consideration in every app and having a consistent API would make >> it much easier get it right. >> >> Would like to hear peoples opinions on this and collect volunteers to >> join a working group. >> >> ~C >> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/4c634f36-bd9c-43d2-a387-90a47f4dad84%40googlegroups.com >> >> <https://groups.google.com/d/msgid/php-fig/4c634f36-bd9c-43d2-a387-90a47f4dad84%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/489e87ce-f5f6-4170-8713-0fa2e489bb8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
