feat(runtime-dom): trusted types compatibility #10844
Conversation
Size ReportBundles
Usages
|
|
|
haoqunjiang
changed the title
haoqunjiang
changed the title
haoqunjiang
changed the title
haoqunjiang
changed the title
__VUE_PROD_TRUSTED_TYPES__ enabled
haoqunjiang
changed the title
__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
yyx990803
force-pushed
the
feat-trusted-types-compat
branch
from
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. |
yyx990803
changed the title
__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
vuepolicy to convert the HTML string output from the Vue compiler to theTrustedHTMLtype.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: