Integrity resources are being blocked

[DoctorOaken]

Current behavior

We have been attempting to use this configuration

experimentalSourceRewriting: true

However when we run our automation we run into this error

Failed to find a valid digest in the 'integrity' attribute for resource 'https://www.xxxxxxxxx.com/js/script.js' with computed SHA-384 integrity 'HASH'. The resource has been blocked

Desired behavior

The resource loads and then the page loads.

Test code to reproduce

We cannot provide this directly, but is there a way we could demonstrate the test?

Cypress Version

13.15.1

Node version

22.9.0

Operating System

Windows 11 , reproducible in Ubunut 20.04 LTS

Debug Logs

No response

Other

We believe we are running into the same problem mentioned on this thread.

#29111
as well as this one
#18315

We tried using these configurations

experimentalSourceRewriting: true and/or modifyObstructiveCode: false,

but we continued to run into the same integrity resource being blocked error.

Attached as a screenshot of the log of the test result.

[ryanthemanuel]

Hi @DoctorOaken. Can you send your full cypress config (with anything sensitive filtered out)? I'm curious what other config values are being set. Also, how is that asset being loaded? Is it part of the HTML or being fetched some other way, etc.?

Forking Cypress Test Tiny makes sharing a reproducible example easier to share and easier for our engineers to replicate your issues. This method also keeps the reproduction as simple as possible, which helps us eliminate potential causes and noise from the investigation.

[DoctorOaken]

Hello,

Thanks for your reply. We have put together a sample of the tests attached to this reply.

minimal_project.zip

[dan-reeves-volusion]

Hi @ryanthemanuel
@DoctorOaken's coworker here,

The asset is just part of the HTML on page, it's a React script

Here's our fork for the test:
https://github.com/dan-reeves-volusion/cypress-test-tiny
EDIT, specific commit:
https://github.com/dan-reeves-volusion/cypress-test-tiny/tree/b199b4a183db11a16c85f972991bc4077a068236

We get the integrity error with the config as it is there.
After turning experimentalSourceRewriting to true, the script loads successfully, however navigating to the OrderFinished page after checkout breaks Cypress: The left panel resets to "Your tests are loading..." and the window becomes mostly unresponsive and cypress must be restarted.

Just a guess, but I think it has something to do with a window.top.location.replace(uri); call in the bundled JS of that React script:
in /checkout/static/js/services/WindowService/index.ts#43 (bundled, not a real file on the server)
Cypress handled it fine before the integrity attribute was present, but I'm guessing experimentalSourceRewriting has some trouble with it. Could be wrong though!

[ryanthemanuel]

Thanks for the reproduction and theories. That was super helpful. I do think there's a bug in our source rewriting capabilities, but I was able to find a workaround that will work for this scenario. If you add this:

        cy.intercept('GET', '*main*.js', (req) => {
            req.continue((res) => {
                res.body = res.body.replaceAll('window.top', 'self')
            })
        })

Basically, this will replace the problematic window.top.location.replace call in such a way that it works with the Cypress iframe. Let me know if that works for you all. It seemed to work locally for me.

I'll keep the issue open since it appears we can do better with our rewriting logic.

[dan-reeves-volusion]

@ryanthemanuel
Hi!
So that cy.intercept() solution worked for some tests, but we ran into another problem. Let me know if I should create a new issue, it still involves experimentalSourceRewriting.

updated Fork:
https://github.com/dan-reeves-volusion/cypress-test-tiny
There's a new spec: cypress/e2e/failing_with_config_test_case.js

What we get now is an integrity error on a script that is created by an inline script on the page:

Cypress chrome console:

I've been scratching my head trying to think of a way around that, but I'm coming up with nothing

[dan-reeves-volusion]

I noticed another thing on that page (one-page-checkout.asp)
There's a very long inline script that starts with
var amazonCheckout = (/access_token=Atza/).test(window.location.href);

That script doesn't seem to load properly with experimentalSourceRewriting on. I did some testing, any very long inline script (about 40460+ characters) runs into issues with experimentalSourceRewriting