2016-07-31 1:49 GMT+05:00 Reinis Rozitis :
> From: Michael Vostrikov
>>
>> The problem is that these functions should be called everywhere manually,
>> and there is no error when these functions are not called.
>> And this RFC proposes a solution - call a function automatically.
>>
>
> Though you
From: Michael Vostrikov
The problem is that these functions should be called everywhere manually,
and there is no error when these functions are not called.
And this RFC proposes a solution - call a function automatically.
Though you can use pecl/taint for that.
If anything imo it would make mo
>
> What you propose is `Foo::escape()` (static), as a language construct.
>
I have changed the RFC, I wrote about it. Please read the description.
There is no more static calls, there is no hacks with not fully qualified
name.
If any templating engine does that, I'd suggest opening an issue on t
On Sat, Jul 30, 2016 at 8:06 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> No! You don't understand what I'm trying to explain.
We understand, that's why we're discussing so much against it.
> This feature will be
> useful for ALL applications without template engine - framewor
> This can be done with e.g. "".
sometimes you also need to sanitize html, e.g.
see http://htmlpurifier.org/
Regards
Thomas
Michael Vostrikov wrote on 30.07.2016 16:01:
>> This new tag will not simply replace because you still need
> to output HTML sometimes.
>
> This can be done with e.g.
> This new tag will not simply replace because you still need
to output HTML sometimes.
This can be done with e.g. "".
> What you've coined "context" is really just a pseudo function-call - it
does not automatically establish context
Yes. Because the language cannot know the task, it cannot kn
> the problem IS NOT that we don't have a solution
> The problem IS that developer
> must call these functions everywhere manually.
What you don't seem to get, is your proposal doesn't change that fact?
It changes the syntax and means by which you select and call the function,
but it still re
> The aim in my mind would be to make escaping easier to do right, for
people who aren't already using a framework or templating engine with its
own solution.
> The current implementation doesn't seem to share these priorities; it
feels like a building block for framework developers, who probably h
Just a thought, but I can't help thinking that "improved escape facilities
and syntax" are a mere patch for a more than superficial problem.
The problem of differentiating HTML strings, which to not require escaping,
from other string, which do, could actually be viewed as a deeper problem,
which
On 28/07/2016 10:39, Thomas Bley wrote:
creating an e() function can be a BC break if people already have an e()
function in their code.
The name e is ambiguous to me, is it escape, error, encrypt?
You are free to provide a better rfc, but having e() being optional will also
make security opti
creating an e() function can be a BC break if people already have an e()
function in their code.
The name e is ambiguous to me, is it escape, error, encrypt?
You are free to provide a better rfc, but having e() being optional will also
make security optional.
Regards
Thomas
Rowan Collins wrote
On 27 July 2016 23:45:10 GMT+01:00, Thomas Bley wrote:
>> In many ways, defining a built-in function e($string, $context) would
>
>> fulfil most of the above.
>
>If things are so easy, why does so much code exist with XSS problems?
Firstly, because there is no such built in function. I don't mean
> In many ways, defining a built-in function e($string, $context) would
> fulfil most of the above.
If things are so easy, why does so much code exist with XSS problems?
Regards
Thomas
Rowan Collins wrote on 27.07.2016 22:57:
> On 26/07/2016 14:15, Michael Vostrikov wrote:
>> Ok. Just ask you,
On 26/07/2016 14:15, Michael Vostrikov wrote:
Ok. Just ask you, why people ask the same question again since the time PHP
was created? Why almost all feature requests mentioned in RFC are about an
easy way to call htmlspecialchars()? You can vote up or down, I just want
to get an official result
On 26.07.2016 at 15:15, Michael Vostrikov wrote:
>> The RFC speaks of *operator*, where actually start-tags[1] are meant, to
> start with.
>> Using the word operator is rather confusing in this context.
>
> Technically yes, but there are echo operator, so it can be considered as
> special constru
Previously you wrote about PHP as a lang only. There was an RFC
https://wiki.php.net/rfc/script_only_include about dissallow opening tags
in require statements - personally I'd love to see it in PHP it could
minimize affect af featores like operator we're talking about to just
templates.
26 lip 20
>> if ($context == 'html') {
> this is bad coding style since $context = 0 gives unexpected html
escaping.
I know, it was just an example)
> The RFC speaks of *operator*, where actually start-tags[1] are meant, to
start with.
> Using the word operator is rather confusing in this context.
Techni
> PHP today is a programming language, and applications and libraries can
be and are written in that programming language.
PHP has and tags, all outside these tags is considered as
HTML. It is needed or to remove these tags and use PHP as programming
language only, or to improve usage of these t
On 24.07.2016 at 19:21, Thomas Bley wrote:
> I'm not sure if it is a good thing to vote against security enhancements.
Most certainly, it is not. :-)
--
Christoph M. Becker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> Frameworks are free to write all sorts of weird shit:
with set_escape_handler(), the "weird shit" is in one place and can be quickly
verified. Now the "weird shit" is spread over all templates.
Normally the problem is not fixing the frameworks, it's most work to fix code
that is using the fram
On 24/07/2016 19:09, Thomas Bley wrote:
Then why is absolutely everything in the current RFC optional and
configurable to the Nth degree?
It's one handler: set_escape_handler() (N=1)
Currently, every framework has it's own methods for escaping. To get this
together, set_escape_handler() is a g
> Then why is absolutely everything in the current RFC optional and
> configurable to the Nth degree?
It's one handler: set_escape_handler() (N=1)
Currently, every framework has it's own methods for escaping. To get this
together, set_escape_handler() is a good choice, similar to set_error_hand
On 24/07/2016 18:06, Thomas Bley wrote:
It's not that difficult to write a static analyser that detects
instances of "
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 pa
> But you still have to rember to use proper escaping function.
I see no problem if companies make a rule not to deploy code containing " I just wanted to give an explanation why I would vote
> against it.
I'm not sure if it is a good thing to vote against security enhancements.
Regards
Thomas
> It's not that difficult to write a static analyser that detects
> instances of " 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 proble
On 24.07.2016 at 18:21, Thomas Bley wrote:
>>
>>
>> instead of
>>
>>
>
> benefits are using static code analyzers, grep " Having function names with single characters is bad taste and only useful for
> obfuscating.
Cryptic "operators", however, are not?
> The big difference is:
> With http
On 24/07/2016 17:21, Thomas Bley wrote:
instead of
benefits are using static code analyzers, grep "
It's not that difficult to write a static analyser that detects
instances of "
Having function names with single characters is bad taste and only useful for
obfuscating.
And having
> The big difference is:
> With https://github.com/phpmyadmin/phpmyadmin/commit/edffb52884b09562490081c3b8666ef46c296418
https://github.com/phpmyadmin/phpmyadmin/commit/75a55824012406a08c4debf5ddb7ae41c32a7dbc
https://github.com/phpmyadmin/phpmyadmin/commit/aca42efa01917cc0fe8cfdb2927a6399ca1742f2
>
>
> instead of
>
>
benefits are using static code analyzers, grep " On 24.07.2016 at 16:55, Thomas Bley wrote:
>
>> In total a good rfc everybody should be happy with.
>
> I'm not happy (to put it mildly) with the RFC as it's now. The RFC
> speaks of *operator*, where actually start-tag
On 24.07.2016 at 16:55, Thomas Bley wrote:
> In total a good rfc everybody should be happy with.
I'm not happy (to put it mildly) with the RFC as it's now. The RFC
speaks of *operator*, where actually start-tags[1] are meant, to start
with. Using the word operator is rather confusing in this co
>
php already uses ?: for ternary operator, so users get a bit confused by using
it for escaping.
>
this allows multiple interpretations:
meaning $a context $b
meaning $a | $b context 'html'
> $b ?>
|> may be used by Pipe Operator rfc, if vote is successful
> if ($context == 'html') {
On 24/07/2016 10:48, Michael Vostrikov wrote:
Operator is compiled into the following AST:
echo escape_handler_call(first_argument, second_argument);
I'm sorry, but this is now so simple it undermines its own argument for
existing.
There is no default handler for any context, to
prevent '
On 24/07/2016 10:42, Michael Vostrikov wrote:
It is a string too, instead of an identifier like in
... IDE will have problem by identify where you have defined it
It should not be identifier or single function name, because in this way we
could not use closures or object methods ($this->escap
On 23/07/2016 20:23, Michael Morris wrote:
PHP was a template engine at inception. [...] something has gone awry when
people are
writing template engines inside of a template engine.
At its inception, PHP was a handful of scripts including access logging
and a guestbook form. You can take a l
I have written many messages already. I think, the purpose of this operator
is clear.
In this discussion I have come up to understanding what I would like to use.
You suggest very hard and complex solutions:
$escape = new SplEscaper; $escape->support('e', function () { ... });
declare('filter=h
> For instance:
> // file1.php
> set_escape_handler('e', 'html_entities_encode');
> // file2.php
> set_escape_handler('e', 'my_own_encode');
> // file3.php
>
>
> If file1.php includes file3.php, it should use first implementation.
> If file2.php does that, so will run the second implementation. I
Not replying to anyone in particular or quoting anything so I'll start
afresh. This is with the topic though, but I'm going to step outside of the
box a bit.
PHP was a template engine at inception. It still is to some degree - hence
braceless syntax. The argument can be made that while the languag
On 07/23/2016 05:23 PM, Rowan Collins wrote:
> On 22/07/2016 15:54, Michael Vostrikov wrote:
>>> The more you compare it to a function call, the less I understand
>>> how it
>> gains over just defining a function e() and writing > 'html') ?>
>>> > I might as well just write "function e($string, $
On 22/07/2016 15:54, Michael Vostrikov wrote:
The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing
> I might as well just write "function e($string, $mode='html') { }"
> they will already have a method of doing this
On 22/07/2016 19:41, David Rodrigues wrote:
Fifth point: you can't use arguments on each escape to change the mean
of what happen, so I need define each possibility (that could be a
lot). For instance: imagine that I have a escape that does, on
reality, a "clamp" that do a $value bet more than mi
The idea is good, but I think that is not pratical in general.
---
First point: we should define each new identifier that could be used.
It not make clear what this identifier does or even how it should
works when a package redefines what it does.
For instance:
// file1.php
set_escape_handler('
> I'm conflicted with this one. For you php "More than 90% of output data -
is data from DB and must be HTML-encoded."
> I have no idea how you came with this, even with applications or websites
I'm working on not using a template engine this is far from the truth.
> especially now that more ans mo
On 22/07/2016 16:54, Michael Vostrikov wrote:
The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing
I might as well just write "function e($string, $mode='html') { }"
they will already have a method of doing this
Ye
> The more you compare it to a function call, the less I understand how it
gains over just defining a function e() and writing
> I might as well just write "function e($string, $mode='html') { }"
> they will already have a method of doing this
Yes, and they have to write a call of it everywhe
On Fri, Jul 22, 2016 at 1:31 AM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
>
> > The trick with the magic class name and namespace aliasing is neat, but
> feels likely to confuse a lot of users
>
> Yes, I have to agree. Maybe more better way is to make it similar to
> set_error_handl
On 22/07/2016 08:31, Michael Vostrikov wrote:
sticking the escaping types after the output makes it hard to spot what's
going on with anything other than a simple variable. e.g. renderView($thing->getViewName(), 'html'), 'js' ?>
In Twig escapers and filters are also written after a variable, an
> sticking the escaping types after the output makes it hard to spot what's
going on with anything other than a simple variable. e.g. renderView($thing->getViewName(), 'html'), 'js' ?>
In Twig escapers and filters are also written after a variable, and this is
not confusing for many users.
{{ rend
On 16/07/2016 16:33, Michael Vostrikov wrote:
Operator has the following form:
[...]
Operator is compiled into the following AST:
echo PHPEscaper::escape(first_argument, second_argument);
Hi Michael,
I'm coming around to the need for (or at least value of) this operator,
but I'm not k
> I suppose you mean that is the unsafe variant.
> How does this rfc makes it not "works good" ? people will still have to
think escaping their data.
It suggests a way when safe variant is as easy as unsafe, without any
additional code. Of course, unsafe variant cannot be removed because of
backwa
On 20/07/2016 21:55, Michael Vostrikov wrote:
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
This is a really good point, Marco.
Of course, this would be much cleaner with a set of functions, since $this
(whatever it is) is not truly a dependency for any of these functions -
they're likely sharing no context or state; they've likely been placed in
the class solely to make them available t
> 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 vari
On Wed, Jul 20, 2016 at 12:17 PM, Michael Vostrikov <
michael.vostri...@gmail.com> wrote:
> > Personally I don't know any developer who is using raw php in project
> without template engine
>
> Zend, Yii, various CMS like Wordperss, internal business-applications - in
> many cases such projects do
The syntax is weird as heck.
That said, frameworks without templating engine already have escaping
helpers, for example:
escapeHtml($value); ?>
escapeHtmlAttr($value); ?>
escapeJs($value); ?>
escapeCss($value); ?>
I don't see what is hard in using that syntax, plus it's not a global
registry.
Ma
> Personally I don't know any developer who is using raw php in project
without template engine
Zend, Yii, various CMS like Wordperss, internal business-applications - in
many cases such projects don't have a template engine.
I usually work with Yii and internal applications on custom engines. Thi
20 lip 2016 19:03 "Michael Vostrikov"
napisał(a):
>
> > You are creating weird most of time unneded quite complex syntax. Just
> use escaping functions or any other escaper or just simply template engine
> as most of people does!
>
> I explained the reasons for implementing this operator in previo
> You are creating weird most of time unneded quite complex syntax. Just
use escaping functions or any other escaper or just simply template engine
as most of people does!
I explained the reasons for implementing this operator in previous
discussion and in the "Problem description" section of the
You are creating weird most of time unneded quite complex syntax. Just use
escaping functions or any other escaper or just simply template engine as
most of people does!
19 lip 2016 21:52 "Michael Vostrikov"
napisał(a):
> > This can be used for all context-dependent text transformations
> On the
> This can be used for all context-dependent text transformations
On the other hand, this is possible now with . And list of arguments will not be needed if the second argument
will be an array. Ok, nevermind.
A couple of thoughts.
Let's just remove default implementation of PHPEscaper. This is not hard to
define own class, in a global namespace or with 'use'.
Maybe allow to pass not limited set of arguments? E.g. like
This can be used for all context-dependent text transformations - not just
for esca
Rasmus
> Do you get my point that a reference to a closure is state? And if it's
global state, that's extremely bad - the entire PHP community is fighting
like hell to avoid that, with PSR-7 and layers of abstraction on top of,
well, everything, in order to make code testable.
What is the differen
2016-07-18 16:29 GMT-04:00 Dan Ackroyd :
> On 17 July 2016 at 04:49, Michael Vostrikov
> wrote:
>
> > If some library really need to replace existing handler of application,
> it can call unregisterHandler() directly.
>
> But then there is no way to restore the previous handler.
>
> > usually we
2016-07-18 16:03 GMT-04:00 Rasmus Schultz :
> > Registry of functions - is exactly how escaping is performed in Symfony
> and Twig.
>
> For one, that does not mean it's a good idea.
>
> For another, the registry in Symfony (at least, I don't know about Twig) is
> inside an instance - it's not glob
On 17 July 2016 at 04:49, Michael Vostrikov wrote:
> If some library really need to replace existing handler of application, it
> can call unregisterHandler() directly.
But then there is no way to restore the previous handler.
> usually we don't need multiple handlers for certain context.
Stu
> Registry of functions - is exactly how escaping is performed in Symfony
and Twig.
For one, that does not mean it's a good idea.
For another, the registry in Symfony (at least, I don't know about Twig) is
inside an instance - it's not global state.
Do you get my point that a reference to a clos
>
> All it is, really, is a registry for functions, and syntactic sugar for
> calling those functions - it's unnecessary, it's more global state you have
> to manage and it's the kind of superficial convenience that will end up
> breeding more complexity.
>
Registry of functions - is exactly how e
> Hacking non FQN resolutions to inject another
> escaper implementation as in "" was a
> creative idea but it seems inconsistent with the preferable "PHP way" to
> handle these edge cases.
Just imagine use cases like:
That way people can use the escaping operator in all kinds of templates w
I've read your RFC, and I think this a strange feature.
All it is, really, is a registry for functions, and syntactic sugar for
calling those functions - it's unnecessary, it's more global state you have
to manage, and it's the kind of superficial convenience that will end up
breeding more complex
>
> Context should be defined where the variable is printed. Otherwise you
> move the variable from HTML text to an attribute or add it somewhere else
> and the context doesn't match anymore.
>
Well, maybe, but HTML is external context and it can be combined with other
contexts depending on task.
2016-07-17 12:35 GMT+02:00 Michael Vostrikov :
> >
> > Multiple arguments would make the syntax even cleaner:
> >
> >
>
> I thought about it. Multiple arguments do not allow runtime modification
> (and make the parser more complex).
> Something like this:
> $context = [];
> if ($field->n
>
> Multiple arguments would make the syntax even cleaner:
>
>
I thought about it. Multiple arguments do not allow runtime modification
(and make the parser more complex).
Something like this:
name == 'url') $context[] = 'url';
$context[] = 'html';
?>
On 2016-07-17 06:49, Marcio Almada wrote:
2 . Is there any rationale why we're using strings separated by '|' to
pass
context instead of an array? Ex.:
Multiple arguments would make the syntax even cleaner:
--
Lauri Kenttä
--
PHP Internals - PHP Runtime Development Mailing List
To unsubsc
>
> 1. Is there any specific reason why we're using a class instead of
> functions to register a callable the same way it's done for exception
> handling or error handling? Hacking non FQN resolutions to inject another
> escaper ...
>
I would not call it 'hacking') This is exaclty the same as if w
> It would be better to return the previous handler, or NULL if one
> wasn't set, in the same way as set_error_handler() does, and for the same
reasons.
Well, maybe you are right.
But I thought, this is not a use case, usually we don't need multiple
handlers for certain context. I.e. we don't need
2016-07-16 11:33 GMT-04:00 Michael Vostrikov :
>
> Hello.
> I have created RFC about context-dependent escaping operator.
> https://wiki.php.net/rfc/escaping_operator
>
> Initial discussion was here: http://marc.info/?t=14661919911
Hi,
A few possible RFC improvements:
1. Is there any specif
Hi Michael,
On 16 July 2016 at 16:33, Michael Vostrikov wrote:
> Hello.
> I have created RFC about context-dependent escaping operator.
> https://wiki.php.net/rfc/escaping_operator
>
> Initial discussion was here: http://marc.info/?t=14661919911
I'm more than slightly sceptical about this RF
> if I see it correctly, this is just a framework for defining callbacks to
a escaping operator, without a implementation of "html" and "js"?
> Not sure if this helps.
There is a default escaping for HTML. If there is no registered handler for
'html' context, it calls htmlspecialchars($str, ENT_QUO
if I see it correctly, this is just a framework for defining callbacks to a
escaping operator, without a implementation of "html" and "js"?
Not sure if this helps.
Regards
Thomas
Michael Vostrikov wrote on 16.07.2016 17:33:
> Hello.
> I have created RFC about context-dependent escaping operator
Hello.
I have created RFC about context-dependent escaping operator.
https://wiki.php.net/rfc/escaping_operator
Initial discussion was here: http://marc.info/?t=14661919911
At first, I wanted to add a call of special function like
escaper_call($str, $context), which performs html-escaping by
79 matches
Mail list logo
