Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94686
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <20160724170644.916231A8060C@dd1730.kasserver.com>
Message-ID: <fee7cd80-0da9-6c92-0783-1d6f54ecaa17@gmail.com>
Date: Sun, 24 Jul 2016 18:41:13 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160724170644.916231A8060C@dd1730.kasserver.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: rowan.collins@gmail.com (Rowan Collins)

On 24/07/2016 18:06, Thomas Bley wrote:
>> It's not that difficult to write a static analyser that detects
>> instances of "<?=" not followed by "h(" or "e(" or whatever.
> <?* and <?= are same for all applications, h() is user-defined. So you need to write a different analyzer for every application if you use h() or e().

This argument is only valid if the RFC includes an implementation, not 
just a syntax. As currently proposed, not even the syntax would be the 
same for all applications, as part of it is hand-waved as up to whoever 
writes the escape callback.


>> Surely the feature gets most of its value from what you *don't* need to
>> do - which is why I think it's bizarre that the current version doesn't
>> even have a built-in HTML escaper at all.
> I think it's no problem to have a follow-up rfc defining some default escapers.

In my opinion, they are central to the feature, not an optional extra.


>
>> It's not possible for multiple frameworks or libraries to declare
>> different escape handlers in your proposal, either.
> not sure I get your point?
>
> public function render($template) {
>    set_escape_handler(['SomeClass', 'methodName']);
>    ob_start();
>    include $template;
>    $content = ob_get_clean();
>    restore_escape_handler();
>    return $content;
> }

OK, so I can dynamically redefine the same syntax to mean different 
things at different times, within the same application. I'm not entirely 
sure that's a particularly good thing.


>> You could equally say, "with <?=e()?> you have to define an e()
>> function". The main effort is remembering to use the right syntax, which
>> you have to do either way.
> the thing here is that people can use <?= without e() and save coding time.

People can use <?= instead of <?* and save learning the difference. Lazy 
people will still be lazy.

Yes, there's a very slight effort saved by it being shorter, but at the 
cost of a minimum PHP version, an extra thing to learn, etc.


> Security cannot be optional, see.

Then why is absolutely everything in the current RFC optional and 
configurable to the Nth degree?

Regards,

-- 
Rowan Collins
[IMSoP]