Skip to content
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

we set the integrity parameter of the cli to true. The generated sha384 encoding did not match that of the actual file. #7429

Open
liuxinyea opened this issue Oct 23, 2023 · 0 comments

Comments

@liuxinyea
Copy link

Version

5.0.8

Environment info

System:
    OS: macOS 14.0
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 14.21.2 - /usr/local/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v14.20.0/bin/yarn
    npm: 6.14.17 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Edge: Not Found
    Firefox: Not Found
    Safari: 17.0
  npmGlobalPackages:
    @vue/cli: Not Found
node:14.21.2
"@vue/cli-plugin-babel": "5.0.8",
"@vue/cli-plugin-eslint": "5.0.8",
"@vue/cli-plugin-pwa": "5.0.8",
"@vue/cli-service": "5.0.8",

Steps to reproduce

set config
{
crossorigin: 'anonymous',
integrity: true,
}
run: vue-cli build

What is expected?

Files can be matched correctly

What is actually happening?

The generated sha384 encoding did not match that of the actual file.


I set the integrity parameter of the cli to true. The generated sha384 encoding did not match that of the actual file. Analysis of the source code found that the plugin was actually the asset obtained in the alterAssetTagGroups hook of the htmlwebpackplugin and generated the hash. Breakpoint debugging found that the asset at this time was not the final content obtained by source(), so the generated encoding did not match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant