Re: RFC about automatic template escaping
| From: | Daniel Beardsley | Date: | Mon, 21 Mar 2016 06:35:46 +0000 |
| Subject: | Re: RFC about automatic template escaping | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-91806@lists.php.net to get a copy of this message | ||
> 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