On Thursday, October 6, 2016 at 6:57:10 AM UTC+2, Fabien Potencier wrote: > > On 10/5/16 12:17, Larry Garfield wrote: > > On 10/05/2016 05:05 PM, Korvin Szanto wrote: > >> > >> > >> On Tue, Oct 4, 2016 at 4:18 PM Sara Golemon <p...@golemon.com > <javascript:> > >> <mailto:p...@golemon.com <javascript:>>> wrote: > >> > >> On Tuesday, October 4, 2016 at 9:40:03 AM UTC-7, Korvin Szanto > wrote: > >> > >> 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;`. > >> > >> > >> There's many different forms of filtering: > >> * Pass filtering (removing of illegal sequences) > >> * Replacement filtering (transformation of illegal sequences with > >> placeholders) > >> * Panic filtering (raise an exception on illegal sequences) > >> * Escaping (included because it's often conflated with filtering) > >> > >> There are whitelist and blacklist variants of these. There are > >> also context sensitive issues for many of these; What's illegal in > >> a JS context isn't the same as an HTML text context, or an HTML > >> attribute context. > >> > >> I don't know that we need standards for these permutations, but I > >> imagine it's a little more than "single interface with a single > >> method". > >> > >> > >> Fair enough, until January my head is still in FIG 2.0 mode. I still > >> would say that the examples you provide can fit into a single > >> interface, but I do see that with FIG 3.0 our scope is probably a > >> little bit different than lowest-common-denominator interface. > >> > >> @Chris I like the idea so far. Escaping is certainly an issue we've > >> had in concrete5 and it's something we've tried to solve in the past > >> with mixed results. One thing that I'd say is it that this kind of > >> filtering might go hand in hand with validation as well. > > > > I'm a bit skeptical here. Such a standard would, it seems, need to > > dictate less an interface and more what happens when you want to escape > > for a given context. How would that be realistically different than a > > universal implementation, which we usually try to avoid? > > > > The audience I'd see for such a spec would be, essentially, template > > engine authors. Vis, how would you make it easy to plug a given > > template engine (where escaping should happen) into an arbitrary > > framework (which provides an escaper)? Or is the escaper part of the > > template engine itself, in which case it's about what the template > > syntax exposes to the user, which is... not what we usually target. > > > > (PSR-3's equivalent question was much more straightforward; make a given > > library compatible with an arbitrary framework-provided logger, which > > was quite successful. I'm not clear on what the equivalent is in this > > case.) > > > > So I think the question to ask here would be: Fabien (Twig) and Taylor > > (Laravel's engine): what would help you in making your template engines > > more portable to other frameworks/applications in a secure fashion, if > > anything? > > Escaping would not make Twig more "portable" (whatever that means), > that's for sure. > > To give some feedback from a project, Twig, that has an escaping > mechanism, you need to keep in mind that this is very performance > sensitive as it is potentially called hundred of times in a page. So, > this part of the code should be highly optimized (Twig only use one > function here, no abstraction, no classes, ... and we use some "tricks" > to make it run fast -- we do have a pull request about extracting this > code to make it reusable but it was never merged because of performance > concerns). So, Twig would not adopt a PSR with interfaces to implement > output escaping. > > For those interested, you can have a look at our implementation here: > https://github.com/twigphp/Twig/blob/1.x/lib/Twig/Extension/Core.php#L977 > > Moreover, I don't see how such a PSR would make projects more > interoperable. What problems are we trying to fix here? >
For me it seems like it would be wiser to have a PSR that would say use such and such method and we have a filtering method that we can trust and people can look and see if a project is using that method. > Fabien > > > > > --Larry Garfield > > > > -- > > 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 php-fig+u...@googlegroups.com <javascript:> > > <mailto:php-fig+u...@googlegroups.com <javascript:>>. > > To post to this group, send email to php...@googlegroups.com > <javascript:> > > <mailto:php...@googlegroups.com <javascript:>>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/php-fig/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.com > > > < > https://groups.google.com/d/msgid/php-fig/3df62d34-af9d-c6b3-5595-07fd246ac8a5%40garfieldtech.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 php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/75aca2d1-18cf-436f-a8d8-6c18f9bbe910%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
