Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94650 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14895 invoked from network); 23 Jul 2016 16:12:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Jul 2016 16:12:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=mathieu@texthtml.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mathieu@texthtml.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain texthtml.net designates 62.210.206.189 as permitted sender) X-PHP-List-Original-Sender: mathieu@texthtml.net X-Host-Fingerprint: 62.210.206.189 texthtml.net Received: from [62.210.206.189] ([62.210.206.189:34235] helo=texthtml.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EF/A1-05797-A5793975 for ; Sat, 23 Jul 2016 12:12:10 -0400 Received: by texthtml.net (Postfix, from userid 65534) id 674EB232; Sat, 23 Jul 2016 16:12:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on 1a9d71b359c7 X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 Received: from [192.168.0.101] (stunnel_mail_1.mail_default [172.27.0.4]) (Authenticated sender: mathieu@texthtml.net) by texthtml.net (Postfix) with ESMTPA id 5B94222A; Sat, 23 Jul 2016 16:12:03 +0000 (UTC) To: Rowan Collins , internals@lists.php.net References: <8a39df34-4a23-c496-15f6-20a62d27fc59@gmail.com> <4920f683-9a4d-7153-b157-a7d7ce8cbfe7@gmail.com> Message-ID: <933449d0-90c2-0d7a-cb80-a171289d8286@texthtml.net> Date: Sat, 23 Jul 2016 18:11:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Thunderbird/49.0a2 MIME-Version: 1.0 In-Reply-To: <4920f683-9a4d-7153-b157-a7d7ce8cbfe7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping From: mathieu@texthtml.net (Mathieu Rochette) On 07/23/2016 05:23 PM, Rowan Collins wrote: > On 22/07/2016 15:54, Michael Vostrikov wrote: >>> The more you compare it to a function call, the less I understand >>> how it >> gains over just defining a function e() and writing > 'html') ?> >>> > I might as well just write "function e($string, $mode='html') { >>> .... }" >>> > they will already have a method of doing this >> Yes, and they have to write a call of it everywhere. New operator can >> remove it. > > This is the part I don't get. How does "using an operator everywhere" > remove the effort of "using a function everywhere"? It's the same > effort in both cases. I to think that's the same effort, however using an escape operator have one advantage imho: you can use a linter to check that all output pass through an escaper. it can still be wrong but its absence can be detected thinking about escaping, it reminded me about ob_start, it takes an optional output_callback that's called on the output data. what if the escape operator was not limited to short tags and worked the same way (except for the buffering part) ? it would ensure that any output within "escape context" would be escaped, eg:

title() ?>

article()->summary(); ?>

and if it's explained that work on the output string data, there is no doubt about that should result in "Array" > > >> The goal is to remove copy-paste for HTML escaping (so it will become >> automatic) > > ... > > the problem is to copy-paste it in 90% places of output data. > > If somebody can't type "e(" and ") without copying and pasting, then > they're going to have a hard time writing any meaningful code. I think means that it's repeated all over the place, not necessarily that it's not written by hand. that said, I'd rather have that repeated all over to make sure you think about the correct context at all times > > >>> On the other hand, if I have an array and ask for it to be >>> HTML-escaped, >> nothing iterates the array for me, it will just print "Array". So if >> I ask >> for it to be "JS-escaped", why should it magically produce a JSON array? >> Yes, I agree, I methioned this in RFC - JSON is not escaping, it is >> encoding in special notation. >> This is one of the reasons why I was disagreed with the need to support >> multiple contexts. >> So, the question is up again - do we really need multiple contexts? > > The reason multiple contexts are needed, in my opinion, is the false > sense of security of saying "we have built-in escaping", but actually > meaning "we have built-in HTML escaping". If the idea of this feature > is to make good escaping habits second-nature to users who don't have > a templating system, then there's a responsibility to remind them that > not all contexts are created equal. > > As for what "JS-escaped" should mean, why not just backslash-escape > quote marks, like you'd ampersand escape double quotes in HTML? > > > var foo=''; > > var foo='World\'s End'; > > >> Yes, PHPEscaper from RFC works that way - PHPEscaper::registerHandler(). >> But it think runtime definition with second variable is more flexible >> way. >> There are external contexts (HTML is one of) and internal task-dependent >> contexts which can be combined with HTML. We cannot know all possible >> tasks. >> And we come again to pipe operator and twig-like syntax. > > More flexible to what end? Why do I need to be able to dynamically > define arbitrarily complex expressions as the filter name? > > Note that what is defined in the RFC currently is *not* similar to > Twig/Smarty, because it views the parsing of the | as *internal* to > the callback, not part of the escaping syntax itself. It allows you to > define an escape callback that instead uses "," as the separator, and > I don't see why that would ever be necessary. > > If you have a new context, give it a name, and register it. As I say, > this is how streams work - you don't register a callback that filters > all filepath strings, you register a prefix for your particular stream > type. > > > Again, the stated aim of this RFC is to make correct escaping easier > than incorrect escaping. That means providing really obvious syntax, > out of the box, for doing the right thing. > > Regards, -- Mathieu Rochette