Re: New escaped output operator

On 20 June 2016 17:40:05 GMT+01:00, "Михаил Востриков" <michael.vostrikov@gmail.com> wrote: >Actually, htmlspecialchars() is needed in all three cases: ... >You may not write htmlspecialchars together with urlencode just because >urlencode encodes all special characters with its own way. So, not needed in all 3 cases then... >Imagine that urlencode does not encode quotes - what function should we >call for its result? Ideally, an escape filter that performs both functions; if the aim is to make things easier, I shouldn't need to think about the need to nest two escape functions. If I still have to use non-obvious combinations of magic syntax plus function calls, the claim of "secure by default" doesn't really stand up. The ~ becomes nothing more than an alias that I still need to remember when to deploy. <script>$('[data-thing-id="<?~ $thing['name'] ?>]').on('click', function(){doThing('<?~ $thing['name'] ?>'});</script> I'm pretty sure the tempting syntax is actively harmful in that situation... >The fact itself, that there were many discussions about it, indicates >that >it is a necessary feature. Popularity is not the same thing as necessity. More relevantly, even when we agree on the problem, the simple solution isn't always the best, sometimes it pays to think a bit more broadly about the problem space. Larry's escaper registration is one example of that. HackLang's XHP is another - rather than thinking about escaping as an action, it gives the compiler richer knowledge of the structure, so it can "know" the right escape syntax. If the compiler could look at my previous example and recognise the attribute, URL, script, and text contexts itself, then you really would have security-by-default. Unfortunately, that too is tricky to generalise - what is the correct escape method for an attribute named "data-my-action"...? Regards, -- Rowan Collins [IMSoP]