Open stkrelax opened 1 month ago
Hi @stkrelax. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:
@magento give me 2.4-develop instance
- upcoming 2.4.x release@magento I am working on this
Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.
Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
Area: XXXXX
label to the ticket, indicating the functional areas it may be related to.2.4-develop
branch@magento give me 2.4-develop instance
to deploy test instance on Magento infrastructure. 2.4-develop
branch, please, add the label Reproduced on 2.4.x
.Issue: Confirmed
once verification is complete. Hello @stkrelax,
Thanks for the report and collaboration!
We have referred to the Dev Docs related to Subresource Integrity
and found the below:
So it seems this is an expected behavior, we need to run the bin/magento setup:static-content:deploy
command to regenerate the hashes.
Let us know if we missed anything.
Thanks
It's not expected behavior, I'm sure this was not implemented with this in mind. People won't generate static assets after every cache flush, that's just ridiculous.
This needs to be refactored, so SRI hashes are generated once and keep being used even after multiple cache flushes. Storing those in cache, makes no sense whatsoever.
This was already discussed on Slack some months ago, it would surprise me if Adobe isn't already fixing this for one of the next releases.
Thanks @hostep for the detailed explanations. We are confirming this issue for further processing.
Thanks
:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-12858 is successfully created for this GitHub issue.
:white_check_mark: Confirmed by @engcom-Hotel. Thank you for verifying the issue.
Issue Available: @engcom-Hotel, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.
@engcom-Hotel please also consider fixing:
Problem 1 all files for all stores are loaded and cause a 6,7 mb big hashmap
Preconditions and environment
Steps to reproduce
Since p8 sri hashes generation is active
Problem 1 all files for all stores are loaded and cause a 6,7 mb big hashmap Problem 2 after cache flush , hashmaps are not generated again and getting lost because save of hashmaps only happens after static deploy
Expected result
only hashmaps for the current store are expected to be generated only hashmaps for used theme are extecpted to be generated cache flush does not remove hashmap or generates them new
Actual result
all stores and themes are hashmapped causing it to be massivly big cache flush leads to empty hashes
Additional information
Vanish after Flush SubresourceIntegrityRepository
Release note
CSP Subresource Integrity Hashes generated storewise CSP Subresource Integrity Hashes wont vanish after cache flush
Triage and priority