Additional improvements to escaping html in our Vue.js codebase #11269
jardakotesovec
started this conversation in
Proposals
Replies: 1 comment
-
I see escaping by default as a requirement :) Extra property to specify HTML content Extra argument for the t() Both are breaking changes, but at this moment, there might be very few people making use of the Vue components, so it's definitely ok to introduce them in my opinion. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Introduction
As first step, we already moved from v-html to v-strip-unsafe-html. Which is using dompurify to ensure, that no harmful JS can be injected there
In 3.6 I would like to refine the strategy further, because we still currently have many
v-strip-unsafe-html
, which are hidden in base components and developer using these components might not be aware of that he is passing data that might be rendered viav-strip-unsafe-html
. Even though security is already covered. It still allows to introduce some html and make our UI looks funky, which is not great for perceived security. And it still allows to some degree to manipulate with our UI.Differentiate between strings and html string in base components
I think its important to have possibility to explicitly opt-in for
v-strip-unsafe-html
in the place where the data are being passed.Good example is our Dialog component, where its possible to pass
message
, which is than passed (hiddenly) tov-strip-unsafe-html
.Solution which I think could work quite well, is that if such general component is introducing option to receive html - it will have explicit props to do so.
For dialog I would suggest that we have:
message
andmessageHtml
, so the creator of the dialog can asses whether he needs html (maybe the translation contains some html tags) or not. Same pattern I believe could be applied to other components as well.HTML in the translation arguments
Than we have use case, where we are passing arguments to the translations. In following scenario, we require html for the translation itself, but we don't want html for the argument (its not submission title, but the reviewer recommendation title):
For that I would like to adjust our translation function
t
to escape arguments by default and introducing new option to allow html for specific field:So when using this in dialog, where we don't want to allow html tags in the title, it would be just
But if its submission title where we do allow html, we could explicitly escaping for the title argument like this:
Beta Was this translation helpful? Give feedback.
All reactions