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

{{{triples}}} #35

Closed
Rich-Harris opened this issue Nov 29, 2016 · 12 comments
Closed

{{{triples}}} #35

Rich-Harris opened this issue Nov 29, 2016 · 12 comments

Comments

@Rich-Harris
Copy link
Member

We'll eventually need some way to inject arbitrary (sanitized? or is that the dev's responsibility?) HTML

@evs-chris
Copy link
Contributor

I think sanitation is largely out of scope here. I'd say allow an optional hook to modify the resulting DOM before dropping it onto the page. If you wanted to make the dev's life a bit simpler, perhaps that hook could be for a visitor function called to filter each node down the resultant DOM tree.

@Rich-Harris
Copy link
Member Author

I think sanitation is largely out of scope here

👍 yeah, reflecting on it a bit I think you're right

@NekR
Copy link

NekR commented Nov 29, 2016

I think sanitization should be the default. It's more often when you need sanitized output than not.

@Rich-Harris
Copy link
Member Author

That definitely hasn't been my experience. The only time you need sanitisation is if you're rendering user input – every time I've used triples it's been to render e.g. a chunk of markdown that I wrote. Also, there are different forms/levels of sanitisation, and you penalise the majority of users if you include all the sanitisation code for everyone who uses triples.

@NekR
Copy link

NekR commented Nov 29, 2016

@Rich-Harris I don't really know how write apps, maybe you always work with people who don't make mistakes, but from my experience people always do and keep forgetting to use the syntax with sanitization. So even if that's only for user's input, it totally makes sense to have sanitization by default.

I don't mean triples here actually, I mean default interpolation syntax should sanitize and have a syntax to explicitly bypass it.

P.S. "should" in an ideal template engine (or whatever with templates) for me. Not that I'm telling to you what you should do or not :-)

@evs-chris
Copy link
Contributor

@NekR the regular interpolators only create text nodes, so there's really nothing to sanitize there. If you want to drop html into the template from a string, you would have to use a triple.

@NekR
Copy link

NekR commented Nov 29, 2016

@evs-chris I see. That makes sense and that's exactly what I meant. Sorry for misunderstanding.

@Rich-Harris
Copy link
Member Author

P.S. "should" in an ideal template engine (or whatever with templates) for me

Makes me think maybe browsers should be responsible for that – maybe a new API, e.g. as well as node.innerHTML = something there should be a node.safeInnerHTML = something. That way you'd have a clearly defined spec determining what is considered 'safe' and what constitutes an XSS vector etc, no room for framework authors to bork things up. One day...

@PaulBGD
Copy link
Member

PaulBGD commented Dec 1, 2016

@Rich-Harris Is Node.textContent what you're looking for?
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent

@azu
Copy link

azu commented Dec 1, 2016

IE has toStaticHTML method, but it is non-standard...

@jacobmischka
Copy link
Contributor

@PaulBGD textContent is what regular {{ }} mustaches do already, this thread is about inserting HTML, which textContent cannot do, and a magical safeInnerHTML could do safely.

@Swatinem Swatinem mentioned this issue Dec 5, 2016
@Swatinem
Copy link
Member

Swatinem commented Dec 5, 2016

The way I implemented it in #124 btw is without sanitization. I think its the responsibility of the template author to do that, and it would be as simple as definiting a helper and calling {{{sanitize(rawHtml)}}}

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

7 participants