Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unescape all values #244

Closed
ForbesLindesay opened this issue Aug 14, 2012 · 15 comments
Closed

Unescape all values #244

ForbesLindesay opened this issue Aug 14, 2012 · 15 comments

Comments

@ForbesLindesay
Copy link

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

@TiddoLangerak
Copy link

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.

@ForbesLindesay
Copy link
Author

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

@TiddoLangerak
Copy link

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.

@ForbesLindesay
Copy link
Author

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

@bobthecow
Copy link

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.

@ForbesLindesay
Copy link
Author

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?

@broql
Copy link

broql commented Aug 18, 2012

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?

@janl
Copy link
Owner

janl commented Aug 20, 2012

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

@ForbesLindesay
Copy link
Author

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.

@broql
Copy link

broql commented Aug 20, 2012

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

@mjackson
Copy link
Contributor

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

@bobthecow
Copy link

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

@ForbesLindesay
Copy link
Author

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.

@NishadKumar
Copy link

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.

jemrobinson added a commit to alan-turing-institute/data-safe-haven that referenced this issue May 12, 2021
jemrobinson added a commit to alan-turing-institute/data-safe-haven that referenced this issue May 14, 2021
jemrobinson added a commit to alan-turing-institute/data-safe-haven that referenced this issue May 26, 2021
- Adds a new CoCalc webapp
- Better handling of mustache expansion (eg. HTML entities)
- Add webapp links to the DSVM desktop
- Update documentation
- Provide access to shared data volume on this VM

# Commits

* Initial standalone CoCalc server

* Move mirror/repository logic into Configuration.psm1 since it was completely determined by the other config file settings

* Allow CoCalc server to access the package repositories

* Deal with multiple mustache delimiters on a single line

* Update PyPI/CRAN URLs on CoCalc as well as compute VMs

* Switched to using mustache templates for cloud-init expansion

* Updated comments

* Added Expand-CloudInitResources function

* Switch to mustache expansion throughout

* Add DNS records for the webapp VMs

* Added a dedicated SRE DNS zone on the SHM DC

* Updated webapp hostnames

* Add webapp links to the DSVM desktop

* Add support for triple-mustache syntax which prevents the contents from being HTML escaped. (See janl/mustache.js#244).

* Added both desktop icons and application menu icons

* Fixed code style

* Removed desktop application entries for webapps

* Added ConvertTo-Base64GZip function

* Use Expand-CloudInitResources and ConvertTo-Base64GZip when deploying a DSVM

* Updated template full config files

* Updated user guide

* Mount ingress container at /data for CoCalc projects

* Added better CoCalc explanation to the user guide

* Added CoCalc to the Work Resources page
jemrobinson added a commit to alan-turing-institute/data-safe-haven that referenced this issue Jun 10, 2021
- Adds a new CoCalc webapp
- Better handling of mustache expansion (eg. HTML entities)
- Add webapp links to the DSVM desktop
- Update documentation
- Provide access to shared data volume on this VM

# Commits

* Initial standalone CoCalc server

* Move mirror/repository logic into Configuration.psm1 since it was completely determined by the other config file settings

* Allow CoCalc server to access the package repositories

* Deal with multiple mustache delimiters on a single line

* Update PyPI/CRAN URLs on CoCalc as well as compute VMs

* Switched to using mustache templates for cloud-init expansion

* Updated comments

* Added Expand-CloudInitResources function

* Switch to mustache expansion throughout

* Add DNS records for the webapp VMs

* Added a dedicated SRE DNS zone on the SHM DC

* Updated webapp hostnames

* Add webapp links to the DSVM desktop

* Add support for triple-mustache syntax which prevents the contents from being HTML escaped. (See janl/mustache.js#244).

* Added both desktop icons and application menu icons

* Fixed code style

* Removed desktop application entries for webapps

* Added ConvertTo-Base64GZip function

* Use Expand-CloudInitResources and ConvertTo-Base64GZip when deploying a DSVM

* Updated template full config files

* Updated user guide

* Mount ingress container at /data for CoCalc projects

* Added better CoCalc explanation to the user guide

* Added CoCalc to the Work Resources page
@wll8
Copy link

wll8 commented Mar 24, 2023

Using {{{ is null and void in this case:

template = `@{emoji}@{text}`
view = {
  text: "http://test.com",
  emoji: "✨",
}
mustache.render(template, view, {}, [`@{`, `}`])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants