Re: RFC about automatic template escaping

From: Date: Mon, 21 Mar 2016 06:20:49 +0000
Subject: Re: RFC about automatic template escaping
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-91804@lists.php.net to get a copy of this message
On Mar 21, 2016 12:53 PM, "Daniel Beardsley" <daniel@ifixit.com> wrote: > > > > T_ECHO (echo, <?=) and T_PRINT (print) now both emit a > > > ZEND_AST_ECHO_ESCAPE node in the syntax tree. > > > > > Interesting approach, I assume an explicit echo $foo; > > takes the > > normal ZEND_ECHO route then? > > No, looking at the code and tests: echo, print, and <?= all end up > parsing to a ZEND_AST_ECHO_ESCAPE which emits a > ZEND_ECHO_ESCAPE op code when compiled. Only inline > html still compiles as ZEND_ECHO. > > > > Which allows instances of HtmlString to pass straight > > > through a > > > template without being modified (skipping the html_entities call). > > > > > IME once you provide an escape hatch, said hatch WILL be used. It's > > not a question of IF. > > For sure, mistakes can be made with any system, but this helps > dangerous code look *more* wrong: new HtmlString($username) > is obviously wrong. And it makes the correct things require little > to no extra code: <?= $username ?> is always safe. > > > For my part, I'd toss the idea of XHP ( > > https://docs.hhvm.com/hack/XHP/introduction ) back into > > consideration > > over something like this. > > XHP is pretty sweet, but I imagine there are a decent number of people > that don't consider using it because it is such a departure from traditional > templating. > > > This approach has the smell of magic quotes which we got rid of for > > very good reason. XHP is much more explicit in separating markup from > > data and relies far less (not at all when you do it right) on escape > > hatches. > > Huh, I don't see similarities to magic quotes at all. That had to do with > attempting to sanitize input data (plenty of problems with that). All > templating systems have a means of making the default output > mechanism perform escaping and a means of preventing that > escaping with, this adds the same for php templates. Not the default (php) output but their default behavior when no specific escape method (or filter/whatever else) has not been specified. This is a huge difference with is proposed here. Not sure about having such features in the core. It does sound like trying to solve a real issue but using the wrong solution or in the wrong place. Cheers, Pierre

« previous php.internals (#91804) next »