-
-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
feat(runtime-dom): trusted types compatibility #10844
Conversation
Size ReportBundles
Usages
|
|
__VUE_PROD_TRUSTED_TYPES__
enabled
__VUE_PROD_TRUSTED_TYPES__
enabled__VUE_PROD_TRUSTED_TYPES__
flag for trusted types compatibility
Am I correct in thinking this also could have a follow up to allow TrustedHTML objects to be passed to v-html? Or is that automatically handled? |
This is automatically handled as this test case shows: https://github.com/vuejs/core/pull/10844/files#diff-5329e45cfbe289d331762479cc76fe38b6657526dc2a9e2cd6f4729baa6b3e44R81-R102 |
Since this is a feat I changed the target branch to |
This isn't a complete fix because `innerHTML` assignment also occurs in `insertStaticContent`. But at least this makes the hello-world app work with trusted types enabled. I'm still figuring out how to add test cases for trusted types. Remaining todos: - [ ] Add test cases for trusted types. - [ ] Fix `insertStaticContent` to be compatible with trusted types, we may need a `vue` policy for that case. - [ ] Add a note in the docs about trusted types compatibility. - [ ] Allow trusted values to be passed to `v-html` and other props, this ultimately fixes vuejs/rfcs#614
…p mounting Because `replaceChildren` isn't supported in all browsers, we still need to use `innerHTML` to clear the container before mounting the app. I left the compat mode implementation in `runtime-core` as is because it doesn't feel right to use a DOM-only API in `runtime-core`.
It seems that the only source of the `content` is the output of `stringifyStatic` in `compiler-dom`. I guess no additional check is needed here.
Setting `textContent` to empty string is the equivalent of setting `innerHTML` to empty string, but it doesn't trigger trusted types policy violation. Though maybe not as clear and performant as `trustedTypes.emptyHTML`, the code is more succint considering that we don't need to check for the existence of `trustedTypes` before using it.
…d default to false
4b8e4ce
to
a608074
Compare
After looking at the implementation, the additional code isn't that heavy and I think it's better to always support trusted types without having to explicitly turn it on for production. This also avoids having to update relevant docs / plugins to support the new flag. |
__VUE_PROD_TRUSTED_TYPES__
flag for trusted types compatibility
This PR introduces a new
__VUE_PROD_TRUSTED_TYPES__
feature flag to enable support for Trusted Types. Addressing vuejs/rfcs#614.For Trusted Types, I created a
vue
policy to convert the HTML string output from the Vue compiler to theTrustedHTML
type.This implementation works with the current enforcement of Google Workspace products without any issue.
In some rare circumstances, where the user explicitly configured allowed policy names and not allowing duplicates (
Content-Security-Policy: trusted-types vue <their-custom-policy>;
without a trailingallow-duplicates
), a second version of Vue on the same web page would fail to create the built-in trusted types policy.This may be solved by allowing users to customize the built-in policy name, but I don't think it's worth the complexity at this moment, considering the low adoption rate of this feature.
Note that the in-browser compiler doesn't benefit from this PR because it's already incompatible with many content security policies anyway.
Remaining todos: