Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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. >>

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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 -

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

>> 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.

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > > 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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') {

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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 () { ... });

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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,

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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 >

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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,

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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. {{

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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.

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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.

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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.

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > 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.

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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: >

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > 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'; ?> ​

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> > 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

> 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,

Re: [PHP-DEV] [RFC] New operator for context-dependent escaping

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