feat(runtime-dom): a new __VUE_PROD_TRUSTED_TYPES__ flag for trusted types compatibility
#10844
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Size ReportBundles
Usages
|
|
|
…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.
lukewarlow
reviewed
May 5, 2024
lukewarlow
reviewed
May 5, 2024
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.
sodatea
changed the title
sodatea
changed the title
sodatea
changed the title
sodatea
changed the title
__VUE_PROD_TRUSTED_TYPES__ enabled
sodatea
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 |
This was referenced May 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: