Open infogulch opened 1 year ago
I'll add notes here.
Searching I found display-as which seems to solve the double-escaping problem similarly to what I was thinking, though they're moving in a different direction template-wise...
Thanks for pointing this out and the detailed issue. I think it'd be the right call to escape html by default wherever possible and give some way of explicitly opting out. This would also follow JSX' lead: https://reactjs.org/docs/introducing-jsx.html#jsx-prevents-injection-attacks.
Just not sure if it's feasible to introduce escaping on the parser level, while also allowing to opt put per node.
To be honest I think this is out of scope for syn-rsx
itself and should be implemented by the library user, or by the framework that's using syn-rsx
internally. The JSX docs you link to are telling: "By default, React DOM any values embedded in JSX before rendering them." It's the library, not the JSX transform, that escapes them.
I can't imagine how a proc-macro could solve problems 3, 4, or 5. If you wanted to build an additional runtime layer on top of it to do that, it makes sense, as long as it's loosely coupled enough to be optional for syn-rsx
users.
I think it's reasonable to expect strings embedded in html to be html-escaped.
I modified the
Node::Text
match arm to callhtml_escape::encode_text_to_string
on string literals in text nodes in this commit as a demonstration: https://github.com/stoically/syn-rsx/commit/96260968e0827ecb392ea2e9b63e1b7f7f3990e7 However, this approach is deficient. First, this implementation will become less useful once theunquoted-text
branch is merged. But more importantly, this doesn't address the bigger issue which is serializing user-generated data into a node which will arrive via some embedded rust code. Further, it would be nice to be able to nest calls tohtml!
but not double-escape the html tags generated by the innerhtml!
.Here are some cases I think would be reasonable to support:
To support Cases 3 and 4 I suspect the best approach will be to wrap the output of
html!
with a newtype that indicates that it will emit correctly escaped html content, where if wrapped again it will not escape twice.Steps
This is probably too big an effort to resolve all at once, here are some intermediate steps that I think would be useful in the meantime:
html-to-string-macro
doesn't do any escaping and that users should be careful to correctly escape inputs to avoid injections.Thoughts?
🏹🎯, 👀☝️🌠🌠