Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94346
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <CADqTB_gsRDq4ZRTSaGZjE0qcQSjVboME-uvwRfOqE6UoMzKVGA@mail.gmail.com>
References: <20160620222835.BC26C1A80609@dd1730.kasserver.com> <14352177-1b49-e2ed-56a3-9a770d0ebf95@gmail.com> <CAEDdnaU35=jGotCRVHx8=i7JnTg7yZOffr4dZtTDJ9vhqTNqtw@mail.gmail.com> <CAEDdnaUo=QwDejnJ64ziY2i-9KbMBgvN-_T7pzR8FfXBK3QHQA@mail.gmail.com> <CAEDdnaWUNpPxnwymdCj5hrOD=P01BmYO+xJD5JHTy98TRHaLuA@mail.gmail.com> <20160630195252.970321A806C6@dd1730.kasserver.com><CADqTB_gsRDq4ZRTSaGZjE0qcQSjVboME-uvwRfOqE6UoMzKVGA@mail.gmail.com>
To: rasmus@mindplay.dk
Cc: smalyshev@gmail.com, michael.vostrikov@gmail.com, internals@lists.php.net, rowan.collins@gmail.com
Message-ID: <20160630224618.A54121A805EF@dd1730.kasserver.com>
Date: Fri,  1 Jul 2016 00:46:18 +0200 (CEST)
Subject: Re: [PHP-DEV] New escaped output operator
From: mails@thomasbley.de ("Thomas Bley")

> What for?

<?html= $foo.$bar ?> is easy to verify

<?= html($foo).$bar ?> is not easy to verify

Regards

Rasmus Schultz wrote on 30.06.2016 22:27:

> I wish you'd think about the bigger issue of autoloading functions,
> which would solve this and many similar problems much more generally.
> 
> I mean, this:
> 
> <?html= $foo ?>
> 
> versus this:
> 
> <?= html($foo) ?>
> 
> What for?
> 
> I don't see the point in inventing new syntax, and introducing a new
> concept, for what is effectively just a limited set of certain
> specific functions.
> 
> We have functions already - rather than adding new features, we should
> improve the features we already have instead, which benefits the
> language as a whole, not just templates. Improving on functions is
> long over due...
> 
> 
> On Thu, Jun 30, 2016 at 9:52 PM, Thomas Bley <mails@thomasbley.de> wrote:
>> I would prefer to have ENT_HTML5 as the default flag included, since normally
>> all new html code is html5.
>> Maybe split voting between <?~ and <?html= which gives a later option for
>> <?json=, <?csv and other contexts.
>>
>> Regards
>> Thomas
>>
>> Михаил Востриков wrote on 30.06.2016 21:35:
>>
>>> I've tried to gather all arguments for and against.
>>>
>>> To be clear. I suggest new operator like '<?~ $value ?>' which is
>>> equivalent of <?= htmlspecialchars($value, ENT_QUOTES | ENT_SUBSTITUTE) ?>.
>>> It is only for HTML context. Flag combination is taken from most popular
>>> frameworks - Symfony, Zend, Yii, and Twig. Of course, exact form of
>>> operator and default flags are the details of implementation.
>>>
>>>
>>>
>>> - You can write short function in userland.
>>>
>>> The problem is not that we have no function. The problem is that the same
>>> action is always repeated, and if we don't repeat it then it leads to
>>> security problems. More than 90% of output data - is data from DB and must
>>> be HTML-encoded.
>>>
>>> There is no such problem with other contexts. If we don't call json_encode
>>> when passing an array or object into javascript, this only breaks the
>>> script, and it will be noticeable, there won't be security problems.
>>>
>>> With new operator we can write or <?~ ?>, or <?= ?>, they are mutually
>>> exclusive, and we need specially write one or another, but with helper
>>> function we have the same beginning <?= and then can write helper function
>>> or not.
>>>
>>> Also there is a problem with function autoloading.
>>>
>>>
>>>
>>> - It is no place for such operators in the language.
>>> It is no place for a such operators in C++, or C#, or Java. But in the most
>>> popular language for web-programming it is very place for such operator.
>>>
>>>
>>>
>>> - There are many other contexts
>>>
>>> HTML is external context, but others are internal task-dependent contexts.
>>> HTML can be used together with other contexts.
>>> HTML context is the main context in every PHP file, and we write <?php at
>>> the beginning to switch it.
>>>
>>> Actually, on web page we have 3 external contexts - HTML, &gt;script> tag,
>>> <style> tag.
>>> PHP+CSS usually is not used. PHP+JS is not just escaping. It is encoding in
>>> special notation.
>>> Escaping can be applied only to strings, but encoding can be applied to any
>>> type of variables.
>>>
>>> Only urlencode is really escaping (and it also can be used together with
>>> other contexts). But urlencode is an internal context. If we construct an
>>> URL, e.g. for filters, we should encode every part.
>>>
>>> $filterUrl = '/my_route/?state=active';
>>> if ($postData['contains_text']) $filterUrl .=
>>> '&contains_text='.urlencode($postData['contains_text']);
>>>
>>> When we write data-attirbute, additional context is task-dependent, but
>>> HTML context is always present.
>>>
>>> <div class="some-class"
>>>    data-url="<?=
>>> htmlspecialchars('/my_route/?state=active&category_id=123') ?>"
>>>    data-settings="<?= htmlspecialchars(json_encode($settings) ?>"
>>>></div>
>>>
>>>
>>>
>>> - Other people will ask about operator for another context
>>> And you can say: We already added an operator for the main web context,
>>> because it is the most frequently used context. If you have a lot of work
>>> with other contexts, please use template engine.
>>>
>>>
>>>
>>> - You want to add new operator just for your needs
>>> It's not only my needs for one project. I meet this problem in many
>>> projects without template engine. The results of the poll, which I wrote
>>> about in my previous message, show that it has a place not only for me.
>>> Some feature requests on http://bugs.php.net with the same question were
>>> created in 2002.
>>>
>>>
>>>
>>> - Some people can use various flags, or use third and fourth parameters of
>>> htmlspecialchars().
>>>
>>> How many such projects of total number of projects?
>>> Default flags can be set to be enough safe. Third parameter can be chaged
>>> via ini_set. Fourth parameter is not required for many cases. Except maybe
>>> when some people encode the data before saving it into database.
>>> Also, new operator is not a replacement for htmlspecialchars, so it could
>>> still be used.
>>>
>>> It just is looked not very good - we use special set of parameters, so you
>>> cannot add operator which we could not use.
>>>
>>> This problem with flags can be solved by adding default value for them with
>>> PHP_INI_USER mode, and getter and setter for it. But I'm not sure you think
>>> this is a good idea.
>>>
>>>
>>>
>>> - Exact flags / Default flags
>>>
>>> In popular frameworks there are the following flags:
>>>
>>> Symfony — ENT_QUOTES | ENT_SUBSTITUTE
>>> Yii — ENT_QUOTES | ENT_SUBSTITUTE
>>> Zend — ENT_QUOTES | ENT_SUBSTITUTE
>>> Twig — ENT_QUOTES | ENT_SUBSTITUTE
>>>
>>> https://github.com/symfony/symfony/blob/f29d46f29b91ea5c30699cf6bdb8e65545d1dd26/src/Symfony/Component/Templating/PhpEngine.php#L421
>>> https://github.com/yiisoft/yii2/blob/c370c17e93f364a843ed7c31e1e1f7fc8caef0a3/framework/helpers/BaseHtml.php#L104
>>> https://github.com/zendframework/zend-escaper/blob/1a855b5f7074607b1260d85c5526a59b1ab36593/src/Escaper.php#L117
>>> https://github.com/twigphp/Twig/blob/f0a4fa678465491947554f6687c5fca5e482f8ec/lib/Twig/Extension/Core.php#L1039
>>>
>>>
>>>
>>> - Tilde sign
>>> There is a good argument about tilde sign. It is absent in keyboard layouts
>>> for some european languages. But it is the details of implementation.
>>> I think it should be special sign which is typed with Shift and is located
>>> rather far from "=" sign. Possible variants are "<?! ?>", "<?@ ?>", "<?^
>>> ?>". First variant looks more suitable.
>>>
>>>
>>>
>>> I don't see any arguments, why other operators can be implemented but this
>>> operator cannot.
>>>
>>> So, please tell me, what do you think about RFC?
>>>
>>>
>>>
>>> 2016-06-29 21:39 GMT+05:00 Михаил Востриков
>>> <michael.vostrikov@gmail.com>:
>>>
>>>> Hello. I've created an article on russian technical site habrahabr.ru.
>>>> https://habrahabr.ru/post/304162/
>>>>
>>>> There is a poll about introducing of such operator. About 60% from those
>>>> people who have projects without template engine are "for" this operator.
>>>> And even a half of those who don't also think that such operator can be
>>>> useful.
>>>>
>>>> I think you can use Google Translate to read it, common sense and code
>>>> examples should be understandable.
>>>>
>>>> https://translate.google.com/translate?sl=en&tl=ru&js=y&prev=_t&hl=ru&ie=UTF-8&u=https%3A%2F%2Fhabrahabr.ru%2Fpost%2F304162%2F&edit-text=&act=url
>>>>
>>>> Current results:
>>>>
>>>>
>>>> How often do you work with the projects with template rendering on PHP
>>>> where template engines are not used?
>>>> 35% (163)  Always
>>>> 22% (104)  Quite often
>>>> 18% (86)   Quite rare
>>>> 25% (117)  Almost never
>>>>
>>>> Voted 470 people. Abstained 116 people.
>>>>
>>>>
>>>> How do you think, such an operator would be useful?
>>>> 56% (264)  Yes
>>>> 44% (207)  No
>>>>
>>>> Voted 471 people. Abstained 121 people.
>>>>
>>>>
>>>> I don't use PHP teplate rendering ...
>>>> 51% (147)  and I think that such an operator is not needed
>>>> 49% (139)  but I think that such an operator will come in handy
>>>>
>>>> Voted 286 people. Abstained 247 people.
>>>>
>>>>
>>>> Screenshot in Russian:
>>>>
>>>> https://habrastorage.org/files/675/9ac/883/6759ac8834044ef0b5a09163c791f376.png
>>>>
>>>>
>>>> 60% are "for" this operator, projects of others 40% will not be affected.
>>>> I think this is a good reason to create an RFC and discuss it on more
>>>> global level.
>>>>
>>>>
>>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>