Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63597
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50842A5A.2020507@sugarcrm.com>
References: <CAO8n+WKuPB7Q6LMUmBNMdtFoXFQguoXWo8OrqEcRqiuDJn5WgA@mail.gmail.com>
	<50842A5A.2020507@sugarcrm.com>
Date: Sun, 21 Oct 2012 23:47:00 -0400
Message-ID: <CAL+t6cEXBWqMP+Xm2CDiZusfWb=GxKVm5ZkyiBXEQ_cpDd+ygA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Charlie Somerville <charlie@charliesomerville.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] HTML escaped short echo tag
From: theanomaly.is@gmail.com (Sherif Ramadan)

On Sun, Oct 21, 2012 at 1:01 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> I'd like to propose a new short tag that echos with HTML escaping.
>
> What is "HTML escaping"? Different contexts need different escaping. For
> outside tags it's one escaping, for tag attribute it's another, for JS
> code context - yet another. Selecting just one use case and integrating
> it into the language is a bad idea - since you are basically saying
> everybody should use this specific case in any case, which is wrong.
>
>> The new tag should be just as short and easy to type as <?=. Personally I'm
>> a fan of <?- or perhaps <?~.
>
> Personally I'm hugely *not* a fan of more obscure syntax in PHP.
> Especially one that will quickly lead people into writing insecure code
> because of applying wrong escaping function for the context.


I completely agree.

Adding a new syntax for automatic escaping (even if configurable --
yay more php.ini!) is not going to change anyone's mindset from
defensive to offensive stance in my opinion.

If you have a template which generates javascript, css, and x/html all
from the same PHP file you get a lot of confusing having to deal with
some new syntax where users now have to be considerate of what output
syntax decides on what escape method.

For this most user-space implementations (frameworks like you
mentioned) do a fine job of identifying these common use cases and
providing a common solution. There's the taint approach which could
allow a framework to automatically figure out which variables are
tainted and should be escaped and which aren't and can pass through
cleanly.

PHP doesn't need to get in the way here. I think the existing userland
implementations should do fine if they get it right.

> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>