I agree XHP really is the right solution for this problem. It enables HTML
to be created structurally and composably with a concise inline syntax,
just like JSX/React does for JavaScript, and just like LINQ does for SQL in
C#. It's* much* better than passing around snippets of HTML as strings that
can easily break.

I'd like to submit an RFC (with a pull request) for adding auto-escaping
to
the php language.

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?

zend_write_escape is a new function pointer that points to
php_escape_write.

Pluggable, good.

The auto-escaping system can be configured with an:
__auto_escape_exempt_class="HtmlString"

I wonder if allowing the classes to declare themselves as exempty (or
self-escapable) might be a better approach.

e.g.
class Foo implements HtmlEscapable {
public function htmlEscape() {
return htmlentites($this->whatever);
}
}

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 my part, I'd toss the idea of XHP (
https://docs.hhvm.com/hack/XHP/introduction ) back into consideration
over something like this.

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.

-Sara

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.

-Sara

Wouldn't this __auto_escape setting effectively break libraries that depend
on it being on or off?

People often write code to generate HTML like this:

ob_start();
?>

<?php
$html = ob_get_clean();

If that code is in a library, it can't be used with this setting enabled.
That could become a real pain point for the whole PHP ecosystem.

Hi Daniel,

On Mon, Mar 21, 2016 at 7:11 AM, Daniel Beardsley daniel@ifixit.com
wrote:

I'd like to submit an RFC (with a pull request) for adding auto-escaping
to
the php language.

We at iFixit.com have used PHP for nearly a decade to run our website.
Several years ago, we abandoned the Smarty templating engine and used php
files directly as templates. This worked, but was a bit unsafe and made
it
too easy to leave user submitted content unescaped. Several years ago we
switched to using a modified version of PHP that included auto-escaping
and
it has been working great. In the process of preparing to use php 7, I've
re-implemented the changes against the master branch.

I'd like to gauge interest in this before I formally submit an RFC.
Here's
a somewhat better description that I've attached to a pull request on our
internal fork of php.

Pull request on internal fork: https://github.com/iFixit/php-src/pull/14

Background

PHP doesn't have any mechanism to inject logic between templating
and final output. There is no way to filter or alter the content
that comes from code in templates like: <?= $someVar ?>

To use php as a robust templataing language, we must inject some
logic between templates and their output. We have chosen to make
all <?=, echo, and print statements subject to an optional
trip through the internal function php_escape_html_entitiles.

The functionality can be toggled with ini_set('__auto_escape')
and configured with __auto_escape_flags and
__auto_escape_exempt_class (see commit

https://github.com/iFixit/php-src/commit/2dae5d16436ce37856f6e00ca2a1b3009bb1f7ed

for info about the class name based auto-escaping exemption.

Methodology

T_ECHO (echo, <?=) and T_PRINT (print) now both emit a
ZEND_AST_ECHO_ESCAPE node in the syntax tree.

That's compiled to a function which emits a ZEND_ECHO_ESCAPE op code.

The op code interpretation is a dupe of ZEND_ECHO except with some
if() statements that switch the underlying function from zend_write
to zend_write_escape based on the ini settings.

zend_write_escape is a new function pointer that points to
php_escape_write.

php_escape_write is a new function that passes it's string argument
through php_escape_html_entities() (with __auto_escape_flags) before
calling the underlying php_output_write.

Use

This functionality allows us to safely use php straight as a
templating language with no template compilation step (as many
other templating libraries have).

See the included tests for more usage information.

Exempt Class

It is useful to allow some utility functions and helpers to produce
html and have it passed straight through in the template (without
being double-encoded). We accomplish this by tagging strings
as being HTML.

class HtmlString implements JsonSerializable {
   protected $html = '';

   public function __construct($html) {
      $this->html = $html;
   }

   public function __toString() {
      return (string)$this->html;
   }

   public function jsonSerialize() {
      return $this->html;
   }
}

The auto-escaping system can be configured with an:
__auto_escape_exempt_class="HtmlString"

Which allows instances of HtmlString to pass straight through a
template without being modified (skipping the html_entities call).
Helper functions can now return html safely and consumers don't have
to care if it is HTML or not because the auto-escaping system knows
what to do.

Thanks for your consideration!
Daniel Beardsley

Issue is "Escaping is done on a specific context".

I understand your proposal is focused on HTML escaping. However,
setting names like
__auto_escape_exempt_class
is not good choice. It has to be
__auto_html_escape_exempt_class
at least because it is for HTML escaping.

In addition, HTML consists of multiple contexts

• HTML context that requires HTML escape
• URI context that requires URI escape
• JavaScript context, embedded JavaScript strings for example , that
  requires JavaScript string escape, etc.
  e.g. http://blog.ohgaki.net/javascript-string-escape (Sorry. It's
  my blog and written in Japanese.
  You may try translation service or you should be able to understand
  PHP code at least)
• CSS context that requires CSS escape.
  e.g. https://developer.mozilla.org/ja/docs/Web/API/CSS/escape
• And so on

Dealing HTML context only would be problematic even if it works for many
cases.

Escaping must be done depends on context. Multiple contexts may apply
also. HTML context only escaping would not work well.. Applying proper
escapes to variables in HTML is very complex task..

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Issue is "Escaping is done on a specific context".

I understand your proposal is focused on HTML escaping. However,
setting names like
__auto_escape_exempt_class
is not good choice. It has to be
__auto_html_escape_exempt_class
at least because it is for HTML escaping.

Yes, the ini settings have poor names and can totally be changed.

In addition, HTML consists of multiple contexts

• HTML context that requires HTML escape
• URI context that requires URI escape
• JavaScript context, embedded JavaScript strings for example , that
  requires JavaScript string escape, etc.
  e.g. http://blog.ohgaki.net/javascript-string-escape (Sorry. It's
  my blog and written in Japanese.
  You may try translation service or you should be able to understand
  PHP code at least)
• CSS context that requires CSS escape.
  e.g. https://developer.mozilla.org/ja/docs/Web/API/CSS/escape
• And so on

You are right. Though not all those problems are serious:

• HTML attributes:
  Use ENT_QUOTES so that content is escaped well enough
  for use in quoted attributes (still need quotes though)
• URI escaping:
  Does anyone really use <?= ?> or echo when generating a uri?
• Javascript:
  Good point, though I would say it's fairly rare to create javascript
  code using a php template with variables. The most we ever do
  in our app is <?= json_encode($someArray) ?>
• Eveything else:
  I think the better solution here is to simply let the user control this.
  Provide an ini setting that allows a custom output function to be set
  so the user could control what happens to unsafe strings and what
  the exemptions are. I'm considering doing this. This was html-only
  at the beginning because we only created this for html templates
  and were able to call the internal php functions directly, ginving
  us nearly no performance penalty.

Dealing HTML context only would be problematic even if it works for many cases.

Escaping must be done depends on context. Multiple contexts may apply
also. HTML context only escaping would not work well.. Applying proper
escapes to variables in HTML is very complex task..

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net