Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.
https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be prolongated if you will decide
that this is too small voting time for such a change.
Voting requires 2/3 support.
Thank you for voting.
This should definitely be a 2 week vote.
- Davey
On Sat, Jul 30, 2016 at 08:09 Michael Vostrikov michael.vostrikov@gmail.com
wrote:
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be prolongated if you will decide
that this is too small voting time for such a change.
Voting requires 2/3 support.Thank you for voting.
Hi!
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.
Thanks, please add start and end dates for voting.
--
Stas Malyshev
smalyshev@gmail.com
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.
I just checked out the cde_new branch to verify the behavior of some
potential edge cases, but after building I've got segfaults even for
sapi/cli/php -n -r ""
That's not a problem per se, as the RFC process doesn't even require an
implementation before voting. :-) Being able to play around with an
implementation would be unlikely to change my vote anyway.
My main issue with this RFC is that I don't consider it to enhance
security. Forgetting to call the proper escaping function is as easy as
forgetting to use <?* instead of <?= or calling an inappropriate
escape_handler_call().
--
Christoph M. Becker
Thanks, please add start and end dates for voting.
Done. Voting is open till August 6, but I think the result is already clear)
but after building I've got segfaults
Probably it is because I didn't add PHP_FE_END at the end of function list.
My main issue with this RFC is that I don't consider it to enhance
security. Forgetting to call the proper escaping function is as easy as
forgetting to use <?* instead of <?= or calling an inappropriate
escape_handler_call().
With such a logic any application is not secure, and any escaping is wrong,
because the user can forget something or call inappropriate function. What
if user wrote {{ str | e }} in Twig template in non-HTML context? Does Twig
not enhance security?
The main problem is with HTML context. With new operator it is easy to
escape a value twice, with standard one it is easy not to escape it.
Users can use new operator instead of standard echo operator, this can be
set as a rule in a code style guide. With standard operator this cannot be
done because somewhere escaping function is required, somewhere not.
Standard operator cannot be removed because of backward compatibility, but
this is not the reason not to add more safer operator.
I have an idea about how to add an escaping without changing the language,
but it will break backward compatibility a little.
It is possible to create an extension, which will override the opcodes for
'bitwise or' with strings and 'echo'.
Echo operator will output only so called 'echo-objects', which are
instances of EchoObject class.
If output value is not an echo-object, it is wrapped into it as 'new
EchoObject($value)'.
Constructions like "$str | $context" become "new EchoObject($str,
$context)".
EchoObject has __toString() method, which will call
escape_handler_call($this->value, $this->context).
$escapedValue = $str | $context; // $escapedValue is EchoObject
echo $escapedValue; // $escapedValue->__toString();
<?= $str ?> // echo new EchoObject($str)
The class is required, because there is no another way how to differ <?=
$str | $context ?> and <?= $str ?> constructions (if $str is already
escaped or not). I'm not sure about performance, but I think it will not be
less than with using template engine.
String constants won't be automatcially escaped, because, as I understand,
any HTML code outside php tags is output as 'echo const_html_string'.
<?= 'test' ?> // won't be wrapped into EchoObject
<?= 'test' | 'html' ?> // will be wrapped into EchoObject
Cases like 'int | string' can be fixed with type casting:
$v1 = 8;
$v2 = '16';
$v3 = $v1 | (int)$v2;
I think, not so many applications use bitwise operations with strings, but
for them some suppressing function could be added.
enable_escaping_echo(false);
$str = '111111' | '222222';
$str = $str ^ '333333';
enable_escaping_echo(true);
The details of implementation of escape_handler_call() can be any, the
global registry for every context (as it was in the RFC) or single callable
(as it is in the RFC), at now it does not matter.
What do you think? Can such extension be added as official extension? I
just have no way to build it for all possible OS and versions.
Le 30/07/2016 à 17:09, Michael Vostrikov a écrit :
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.
Hi,
Even if it could seem interesting at first, typically for beginners
(hoping they use this operator instead of the current ones), we at AFUP
would be on the -1 side.
Basically, our main reasons: "it feels a bit too magical" and "the
escape function is set globally" (both points being partially linked).
In any case, thanks for your work on this!
--
Pascal MARTIN, AFUP - French UG
php-internals@afup.org" rel="nofollow" target="_blank">http://php-internals@afup.org
Looks like it's unanimously a No.
Michael, don't be discouraged - I think that everyone agrees that there is
a problem to be solved, it's just that no one except you thinks this is a
good solution; many of us are of the opinion that it's not a solution that
really addresses the problem at all: you haven't eliminated the choice of
whether or how to escape something, you've merely changed the scope of that
choice - into global state, which clearly isn't popular.
I encourage you to keep thinking about this problem, but you should explore
entirely different directions - rethink and rephrase the problem, get to
the core of it, and a different angle on the problem might reveal itself.
On Sat, Jul 30, 2016 at 5:09 PM, Michael Vostrikov <
michael.vostrikov@gmail.com> wrote:
Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be prolongated if you will decide
that this is too small voting time for such a change.
Voting requires 2/3 support.Thank you for voting.
it's just that no one except you thinks this is a good solution
it's just that no one - who is allowed to vote and wants to vote - thinks this is a good solution.
Regards
Thomas
Rasmus Schultz wrote on 07.08.2016 13:06:
Looks like it's unanimously a No.
Michael, don't be discouraged - I think that everyone agrees that there is
a problem to be solved, it's just that no one except you thinks this is a
good solution; many of us are of the opinion that it's not a solution that
really addresses the problem at all: you haven't eliminated the choice of
whether or how to escape something, you've merely changed the scope of that
choice - into global state, which clearly isn't popular.I encourage you to keep thinking about this problem, but you should explore
entirely different directions - rethink and rephrase the problem, get to
the core of it, and a different angle on the problem might reveal itself.On Sat, Jul 30, 2016 at 5:09 PM, Michael Vostrikov <
michael.vostrikov@gmail.com> wrote:Hello. The RFC 'New operator (short tag) for context-dependent escaping' is
now in voting phase.https://wiki.php.net/rfc/escaping_operator
This RFC introduces new short tag/operator, which will perform echo with an
automatic call of escaping function.
Voting is open till August 6, but it can be prolongated if you will decide
that this is too small voting time for such a change.
Voting requires 2/3 support.Thank you for voting.