angular-cli: Subresource integrity / filename hash inconsistency
Versions
Angular CLI: 1.6.3
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router
@angular/cli: 1.6.3
@angular-devkit/build-optimizer: 0.0.36
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.42
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.3
@schematics/angular: 0.1.11
@schematics/schematics: 0.0.11
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0
AND
Angular CLI: 1.6.4
Node: 9.3.0
OS: darwin x64
Angular: 5.2.0
... animations, common, compiler, compiler-cli, core, forms
... language-service, platform-browser, platform-browser-dynamic
... platform-server, router
@angular/cli: 1.6.4
@angular-devkit/build-optimizer: 0.0.38
@angular-devkit/core: 0.0.25
@angular-devkit/schematics: 0.0.48
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.9.4
@schematics/angular: 0.1.13
@schematics/schematics: 0.0.13
typescript: 2.5.3
webpack-bundle-analyzer: 2.9.2
webpack: 3.10.0
Repro steps
I don’t have a minimal reproduction, but here is a gist to two yarn lockfiles: https://gist.github.com/karptonite/925a56d957a34ff65063d52e619f7fcc
Observed behavior
when building with --prod --subresource-integrity:
The subresource integrity SHA hash can change without the hashed filename changing as dependencies are updated.
In the two yarn lockfiles shown, nothing that is included in polyfills changed, and the hashed filename (--output-hashing all, since --prod is set) remains unchanged between builds. However, because some other dependencies were updated (notably, the uglify version changed), the integrity SHA hash changed. That is a problem because our js is served by a CDN, which assumes that if the filename remains unchanged, it can continue to serve from the cache.
Desired behavior
When anything that can affect the content of the minimized file changes, that should change the filename hash. This could be accomplished by naming the file based on the minimized code, but it could also be as simple as hashing in the version numbers of the relevant packages involved in minimizing the code when generating the filenames.
If you are unable to reproduce this, let me know, and I’ll see if I can figure out how to reproduce it. I got stuck (working in a minimal project) trying to force yarn to downgrade the version of uglify to match what is in my production yarn lock above.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 9
- Comments: 27 (4 by maintainers)
Commits related to this issue
- fix(angular): disable subresource integrity See https://github.com/angular/angular-cli/issues/9338 for more information — committed to pascaliske/pascaliske.dev by deleted user 5 years ago
can we get this fixed soon? I know it’s “inconvenient” and we can clear the cloudflare cache when it happens but… when doing daily deploys with about 100 different domains it’s getting past the point of “inconvenient” and more like a royal pain in the ass. o yeah then there is the whole issues of telling everyone to clear their cache because their browser is caching the files for a year.
Ahh I just saw the contenthash is already being used, I inferred it can’t be since the hashes were the same …
At least I’ll share data to reproduce below, maybe someone can see what I’m missing
index.html no caching *.js 7 days caching
cached runtime
actual runtime
in actual index.html
sha384 sums: cached: VDinAQO6iY5043Owfl98myR/zDHxFa9Q0jmbWqE1YxjijsC49QdU2tDIw0775Biw base64: actual: gyhzYjNbRNkm0kVr49UbYE+nlkhh8oeH2mMogqSClQCO/fgki/miELyW/YJhdIri
for some reason, they both don’t match the integrity hash from the index.html
Chrome 76 output:
Can we please please fix this subresource-integrity is now useless and actually prevents the code from working correctly because the hash doesn’t match
We have a very aggressive 1 year caching policy and now I’m fixing this at the crack of dawn since we have about 20+ people not being able to use our app
I’ve had similar issues and am currently trying a postbuild script in my package.json to update the runtime file in the html. A bit of a hack, but it may solve the problem.
It seems to work for me and may help others
This issue is related to bug in webpack-subresource-integrity plugin, that was fixed in version 1.3.2: https://github.com/waysact/webpack-subresource-integrity/issues/101
Therefore I guess raising the version of webpack-subresource-integrity to 1.3.2 should help (it worked for me locally with npm-shrinkwrap)
I’m using angular cli 7.0.5 and it has pulled in webpack 4.19.1
We are being hit by this bug too.
Consider that the runtime.js file may be in the end user’s browser cache so that purging the CDN cache doesn’t help.