Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91803
Return-Path: <jesseschalken@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 62201 invoked from network); 21 Mar 2016 06:05:04 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 21 Mar 2016 06:05:04 -0000
Authentication-Results: pb1.pair.com header.from=jesseschalken@gmail.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=jesseschalken@gmail.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.182 as permitted sender)
X-PHP-List-Original-Sender: jesseschalken@gmail.com
X-Host-Fingerprint: 209.85.213.182 mail-ig0-f182.google.com  
Received: from [209.85.213.182] ([209.85.213.182:37592] helo=mail-ig0-f182.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 6A/60-58932-E0F8FE65 for <internals@lists.php.net>; Mon, 21 Mar 2016 01:05:03 -0500
Received: by mail-ig0-f182.google.com with SMTP id kc10so61162445igb.0
        for <internals@lists.php.net>; Sun, 20 Mar 2016 23:05:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date:message-id:subject
         :from:to:cc;
        bh=Uu60zZalqEwUfYHqkiFuQmCTA/ubrFPk3cEaahK2OT0=;
        b=gxQeCZ0WmTWEfRyVbN3ZCO4A5mTN2bRfXGDxldBw98EjVD+1/bGmgcqy+sp3mUNqEL
         Vtpga4a/C9F/dphKuItPe0JuL5CrQCwwVVbBROW8ykOIwMq77CmPT8oB16OU2Ts9foTO
         agjMuvSEHL0LKM3HroMiIBFknttZvDIhrvVJpgrMRHhkRsvO6VEmHCMij7y6ycolBDiI
         WuDOeq8/jDm6xy8kR8FTpSY3zraOZJ6VdO4OAFovoJUrbYEob82J9KomJe9jj85qarW6
         UokpDmjOKsFd6miOpxxB8O1gOIWBXLJew+1OPPK6OSfAx6btRKTwUCDP3a7KRCdgzlss
         Bwjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
         :message-id:subject:from:to:cc;
        bh=Uu60zZalqEwUfYHqkiFuQmCTA/ubrFPk3cEaahK2OT0=;
        b=j6m0a0qMfAF4ruBLp8rtBIfEZ8lEoZJ8kR5t37IPSz9qKCZf8Yd49GQ0xLfVheUVKt
         wiltzsD/Z2LvacNkuo40gF4a7sV+XjAy/0RZ3nKmqt/IcawO48zVUx4MkxAowkCJn5Z3
         SV5OnOAG19GrIbZC/KRSuibxoFIbPqQOt0hNo7Gsxue2yjhNepFvl0UfvBxJ+VaFKquI
         ObDnMzvxQcuCAjVG7buLzcyWq9O9dr8LpINeqFWDPvfO/L11lDME1cv9tU4lHlm76b6a
         7bHMt5KMbx/APhw/vrZCBFAriy5HL/6iz9UCCBnb9F0wcnIF7EuJnf3hYsKwvbJxxGMX
         V9lw==
X-Gm-Message-State: AD7BkJLxVBIMQKQXVoL6CScEu+6MCXzgz//VwM9uqlr7OrZDah9nXlzal+D16UY4b2cuRsr5kOx2iz0IJxTYhw==
MIME-Version: 1.0
X-Received: by 10.50.28.72 with SMTP id z8mr10105438igg.44.1458540300525; Sun,
 20 Mar 2016 23:05:00 -0700 (PDT)
Sender: jesseschalken@gmail.com
Received: by 10.79.100.199 with HTTP; Sun, 20 Mar 2016 23:05:00 -0700 (PDT)
In-Reply-To: <CAGa2bXbjNQXwVsFmGgFVUPCFV-t2Tye+xA3MDNpA_ydjvCQ3jA@mail.gmail.com>
References: <CACNm7o9-6z0rxAAxnWyUFhYU+YD-QnecWrJF-PQ=z+a9qNQ=EA@mail.gmail.com>
	<CAGa2bXbjNQXwVsFmGgFVUPCFV-t2Tye+xA3MDNpA_ydjvCQ3jA@mail.gmail.com>
Date: Mon, 21 Mar 2016 17:05:00 +1100
X-Google-Sender-Auth: sXj2pzjqeEwNu4HhTXmfsxR2fdY
Message-ID: <CAF1yvAR3DP_i8Q-8Qk3hxtE7=YCLF+pTCLvs2-WUqCqp5B2Pgw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Daniel Beardsley <daniel@ifixit.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158b24280e9ec052e88e051
Subject: Re: [PHP-DEV] RFC about automatic template escaping
From: me@jesseschalken.com (Jesse Schalken)

--089e0158b24280e9ec052e88e051
Content-Type: text/plain; charset=UTF-8

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();
?>

<div>some HTML <?= escape_html($other_text) ?></div>

<div>more HTML <?= $other_html ?></div>

<!-- etc -->

<?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.


On Mon, Mar 21, 2016 at 3:53 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0158b24280e9ec052e88e051--