Mustache.js: Unescape all values

Created on 14 Aug 2012  ·  14Comments  ·  Source: janl/mustache.js

would it be possible to add an option to not do any escaping of html at all?

Most helpful comment

I haven't tested it, but according to the man page:
All variables are HTML escaped by default. If you want to return unescaped HTML, use the triple mustache: {{{name}}}.
If that doesn't work you could use a function which simply returns it's input unescaped.

All 14 comments

I haven't tested it, but according to the man page:
All variables are HTML escaped by default. If you want to return unescaped HTML, use the triple mustache: {{{name}}}.
If that doesn't work you could use a function which simply returns it's input unescaped.

Yeh, that's the current behaviour but my use case for this has extremely well trusted input and lots of special characters.

I was refering to this part:
If you want to return unescaped HTML, use the triple mustache: {{{name}}}.
So if you don't want your variables to be escaped you should use the triple mustache instead of the double.
Edit: I've tested it and this is correctly implemented in this implementation.

Yeh, was wondering if there might be a useful shortcut to change the default behaviour.

Some implementations have supported an inverted escape pragma in the past (mustache.php v1.x, ruby v0.8ish). This essentially swapped the meaning of {{ foo }} and {{{ foo }}}. It comes in handy for non-html use, like ini files, since escaping html entities makes no sense in that case, and it saves you a bunch of extra mustaches.

Mustache.php v2.x doesn't support this pragma, though. We opted instead for a custom 'escape' option, allowing users to pass an alternate escape callback. Passing function($text) { return $text; } turns escaping into a no-op.

Hmm, that would fit my use case exactly. Is it possible to do that in mustache.js, and if so, where would you pass that function?

Right, it's ok to stick to OWASP guidelines but escaping at all times is not useful in some cases. Is there any ETA for this issue to be completed?

Wouldn't it be easier to just swap {{{ and {{ in the parser in your installation?

At the moment I just run:

template.replace(/\{\{([^\}]*)\}\}/g, '{{{$1}}}');

on all my templates before executing it, which does work. It would just be nice to have a more built in system. I quite like @bobthecow's suggestion as it would allow you to escape other things if you needed to. e.g. if you had a JSON like format rather than XML like you might want to escape quotes/commas/colons etc.

@janl what if I want to render same template in two scenarios: first escaped, second unescaped?

@bobthecow We could easily take the same approach in mustache.js and just use the exported version of Mustache.escapeHtml for all escaping. That would allow users to do something like:

Mustache.escapeHtml = function (text) { return text; }

Would that be useful? Of course, you would need to be careful to reset the value of the function if you want escaping to work properly on subsequent invocations, and you wouldn't be able to decide to escape with the triple-stache.

:+1: I dig it. As far as I can tell, the main use case is disabling escaping entirely, because it's a non-HTML document. I don't see much use for swapping escape/noescape (which is why I didn't even implement it in Mustache.php v2).

Yeh, that would definitely fulfil my use case, and I can envisage some other people using it as say:

Mustache.escapeHtml = function (text) { return text.replace(/\"/g, '\\"'; }

to escape strings. Or they might implement white-listing functions. In short it would fix all the use cases I can think of.

I haven't tested it, but according to the man page:
All variables are HTML escaped by default. If you want to return unescaped HTML, use the triple mustache: {{{name}}}.
If that doesn't work you could use a function which simply returns it's input unescaped.

Thanks a ton!! This works.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SmasherHell picture SmasherHell  ·  18Comments

MatthijsZw picture MatthijsZw  ·  18Comments

amper5and picture amper5and  ·  5Comments

kuldeepdhaka picture kuldeepdhaka  ·  9Comments

rlightner picture rlightner  ·  7Comments