Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94168
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <14352177-1b49-e2ed-56a3-9a770d0ebf95@gmail.com>
References: <20160620222835.BC26C1A80609@dd1730.kasserver.com> <14352177-1b49-e2ed-56a3-9a770d0ebf95@gmail.com>
Date: Tue, 21 Jun 2016 09:51:48 +0500
Message-ID: <CAEDdnaU35=jGotCRVHx8=i7JnTg7yZOffr4dZtTDJ9vhqTNqtw@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Thomas Bley <mails@thomasbley.de>, PHP Internals <internals@lists.php.net>, 
	rowan.collins@gmail.com
Content-Type: multipart/alternative; boundary=001a1146eb6235b9b20535c294d2
Subject: Re: [PHP-DEV] New escaped output operator
From: michael.vostrikov@gmail.com (=?UTF-8?B?0JzQuNGF0LDQuNC7INCS0L7RgdGC0YDQuNC60L7Qsg==?=)

--001a1146eb6235b9b20535c294d2
Content-Type: text/plain; charset=UTF-8

> So, not needed in all 3 cases then...
So, we can still use <?= operator.


>> Imagine that urlencode does not encode quotes - what function should we
>> call for its result?
> Ideally, an escape filter that performs both functions; if the aim is to
make things easier
No. The second function really depends on context, but HTML context is
always present. The aim is to create a shortcut for HTML escaping, decrease
copy-paste, and increase security.


> I shouldn't need to think about the need to nest two escape functions.
> the claim of "secure by default" doesn't really stand up.
This is about super-universal-operator. I did not suggest "secure by
default". As Thomas said, this is just an alias, not more, not less.


> <script>$('[data-thing-id="<?~ $thing['name'] ?>]').on('click',
function(){doThing('<?~ $thing['name'] ?>'});</script>
> I'm pretty sure the tempting syntax is actively harmful in that
situation...
You should not call htmlspecialchars inside script tags, even without <?~
operator. Because this is not an HTML context.


> HackLang's XHP is another - rather than thinking about escaping as an
action
> If the compiler could look at my previous example and recognise the
attribute, URL, script, and text contexts itself
This is very complex solution, and it can make some issues with
performance. Also, as I understand, it just calls htmlspecialchars.
https://github.com/facebook/xhp-lib/blob/master/src/core/XHP.php#L68
https://github.com/facebook/xhp-lib/blob/master/src/html/Element.php#L122


> what is the correct escape method for an attribute named "data-my-action"
It should be HTML-encoded, because it is HTML markup.


> And that is exactly the problem. Inventing operators to alias one
> invocation of one function with one specific set of parameters is not a
> good idea, unless there is a *VERY* good reason to do it.
The call of htmlspecialchars is very frequent case, specific set of
parameters (HTML context) is always present. Is it a very good reason?


> And the case for this specific piece of code to deserve its own operator
is rather weak.
Why do you think so, why is it weak?) As I showed, HTML context is always
present, even if we write inline javascript in 'onclick' attribute.
This is not another context, there are 2 contexts together, and there is no
needs to determine it inside compiler - one context is always here.
So, it deserve its own operator.



Let's summarize.

We must not call htmlspecialchars() in the following cases:

Inside <style> tag
This is very specific case. CSS is usually stored in static files.

Inside <script> tag
This is more frequent case, but usually it is used when we need to pass a
big object from PHP into Javascript. And here is not just escaping, here is
a special notation - JSON.
For small pieces of data JSON also can be used, but it's better to use
data-attributes. And here we need to call htmlspecialchars.

Text files
Text files with PHP processing can be used in code generators. Standart <?=
operator is enough here.

Any other cases and their combinations are very specific. For XML
htmlspecialchars is also enough.

So, my question is - can I create an RFC or there are any arguments
against? I think I explained why all arguments above are unsuitable.



2016-06-21 4:35 GMT+05:00 Stanislav Malyshev <smalyshev@gmail.com>:

> Hi!
>
> > As mentioned a few times in this thread, <?~ is an alias for <?=
> htmlspecialchars(, not more, not less.
>
> And that is exactly the problem. Inventing operators to alias one
> invocation of one function with one specific set of parameters is not a
> good idea, unless there is a *VERY* good reason to do it. And the case
> for this specific piece of code to deserve its own operator is rather weak.
>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a1146eb6235b9b20535c294d2--