On 20/07/2016 21:55, Michael Vostrikov wrote:
<?= $this->escapeHtml($value); ?>
I don't see what is hard in using that syntax, plus it's not a global
registry.
if people aren't using templating and haven't written any of their own
wrappers to sanitize the output
They HAVE own wrappers. The problem is that unsafe variant works good, but
unsafe variant should not work good.
I suppose you mean that <?= $row['data'] ?> is the unsafe variant.
How does this rfc makes it not "works good" ? people will still have to
think escaping their data. And they should: I don't know of any proposal
that makes the safe choice on behalf of the user correctly
anyway, helping escaping data is a good goal and having something easier
than htmlspecialchars would definitely help IMHO
that's what is actually safe without helper or additional template
engines : <?= htmlspecialchars($row['data'], ENT_QUOTES | ENT_SUBSTITUT) ?>
and with a helper: <?= $this->html($row['data']) ?>
here is what it could look like with the rfc : <?* $row['data'], 'html' ?>
and what it might look like with function autoloading: <?=
html($row['data']) ?>
that's why people here are talking about function autoloading, it's not
what this rfc is about but a lot think it would be a better solution
(and would also help in many other places)
speaking only for me now, between the function autoloading and this rfc,
I do prefer the function autoloading. but, I still think the helper
solution is best: easier to mock and thus to customize, extend or
configure (eg: differents htmlspecialchars flags)
something else about the rfc:
> It may seem that different escaping is required here. But it's not.
The call of htmlspecialchars() is required in all 3 cases
I disagree with that, htmlspecialchars is needed in all 3 cases, but
it's not enough
To be a valid page, the html should be valid, and the javascript in it
should be too. htmlspecialchars + json_encode is the correct way to
encode a javascript string inside an html page. if you only use
htmlspecialchars you have valid html, but the page in itself might not
be valid and you could inject javascript code that way. in other words,
it's also a security issue to forget to call json_encode there.
That's not much of an issue anyhow as your rfc handle context stack anyway
One good thing I like about having another syntax <?*$data, $context ?>
or whatever is that you could configure your linter to throws errors
when using <?= $data ?>
And that's not something that could be done easily with function
autoloading or template helpers
and lastly about the syntax, I'm not a huge fan of separating the data
from the context using a comma, I was thing about something like that
instead:
<?[$escaper...]= $data ?>
where $escaper is a callable eg:
<?[$this->html]= $data ?>
<?['e::html']= $data ?>
<?[new Escaper\HTML(ENT_QUOTES | ENT_SUBSTITUT)]= $data ?>// you should
not do that
<?[function ($data) {return htmlspecialchars($data, ENT_QUOTES |
ENT_SUBSTITUT);}]= $data ?> // you should not do that
<?['e\html']= $data ?> // with function autoloading
or multiple escapers:
<?['e::html', 'e::attr']= $data ?>
<?['e::html', 'e::json']= $data ?>
and if you want to say "I know this data is already escaped":
<?[]= $data ?>
it does not need a global state and will be able to take advantage of
new features and uses standard procedure to "register" callable escapers
<?['e::html', 'e::attr']= $data ?> would mostly equivalent to <?=
array_reduce(array_reverse(['e::html', 'e::attr']), function ($data,
$escape) {return $escape($data);}, $data) ?>
it does not need a global state as it uses standard procedure to
"register" callable escapers and will still be able to take advantage of
new features
The problem is that they have to keep in mind that they need always write a
wrapper, they always need to repeat the same action again. And somewhen
they just miss this and get possible problems with security.
The problem is that this is very frequent case, so we need a tool for this
case, which will prevent wrong work (XSS in particular).
We always perform an output to some context. Why just not to add an easy
tool for work with contexts?
This is just one call - PHPEscaper::escape(). Consider it like a Facade
pattern.
what's going to drive them to change?
Why then many people are asking about this feature?
In my RFC there are 10 links to similar discussions. They are from those
people who was not lazy to write to mailing list or bug-tracker.
There are also the results of the poll - 286 people are for this operator
(now 320, after I wrote about implementation with contexts).
And in first message I asked about official poll from PHP developers. Why
not conduct it?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
