chromeWebSecurity: false not working when destination has x-frame-options set to sameorigin

EDIT: Very important to note this only happens when target of redirect has x-frame-options set to sameorigin

Should chromeWebSecurity: false prevent this error?

• Operating System: MacOS
• Cypress Version: 2.1
• Browser Version: Chrome 65

Is this a Feature or Bug?

Bug

Current behavior:

Setting chromeWebSecurity to false is not turning off web security when destination of redirect has x-frame-options set to sameorigin

Desired behavior:

Setting chromeWebSecurity to false should turn off web security

How to reproduce:

Try do to a javascript redirect (see example code) during a cypress test.

Test code:

window.location.href = 'https://www.google.com'

Additional Info (images, stack traces, etc)

This was working for me last week. Same code this week is not working. The site I’m redirecting to has X-Frame-Origin set to sameorigin.

[brian-mann]

@checklist @fahrradflucht the solution today is to change your approach and not change Cypress. I / we understand the need to journey across domains but it is not possible to build a tool that is superior to all existing tools (architecturally) without introducing trade offs. We don’t control W3C or browsers or the security rules that govern how the entire web fits together.

We’ve created a superior product to test the vast majority of situations - namely where you reside on a single superdomain. This is the domain that you control. With that said, we’re aware there are situations that involves exchanging data between services. However, you can always bypass these. What we’re saying is that rather than making Cypress do backflips to try to accommodate this situation, we believe it can by entirely bypassed altogether by approaching it differently - and one that is within your control that will work deterministically 100% of the time.

Will this take more work up front - rather than writing a script that behaves exactly the way your application does to real users? Yes, in this one case it will, but it will better set you up for long term success and enable you to still test all of the edge cases and situations without leaving yourself vulnerable to things outside of your control. This is a core tenant of Cypress, it makes the hard things easy, but it makes some seemingly simple situations harder. There is no free lunch here because we don’t control everything at our whim to make this possible. If we updated our architecture to make this one particular situation easy, then we would be inheriting the entire zoo of problems that Cypress itself has bypassed by redesigning the automation layers from the ground up. If you specifically need the functionality that enables you to cross domain services, you can already use the myriad of other automation tools that enable you to do just that. The problem is though, is that approach on those tools doesn’t work well for the reasons why we don’t actively support them in Cypress.

Read these two best practices for more information:

• https://docs.cypress.io/guides/references/best-practices.html#Organizing-Tests-Logging-In-Controlling-State
• https://docs.cypress.io/guides/references/best-practices.html#Visiting-external-sites

You can with nearly 100% guarantee bypass the need to interact with the other domain by simply using cy.request or using cy.stub in your application. When you want to interact with the other service, you don’t “start there” - you use cy.request to get the thing out of the service and then you “start” with your application already having received that state. Maybe it’s a token in the URL you set as a cookie or in local storage.

As far as wanting to test redirection to another domain - that part is easy too. Why do you even need a browser to do that? Couldn’t you just make an invalid API request and see that your server send a 301 redirect to the correct URL? Because Cypress attaches your browsers cookies to cy.request you could simply use that to know whether the redirect is happening. You could even involve the DOM if this event is triggered by something in your application.

cy.get('a').then(($a) => {
  const href = $a.prop('href')

  cy.request(href).then((resp) => {
    // make sure we've been redirected
    // to where we expect to be
    expect(resp.redirectedTo).to.eq(....)
  })
})

If your server is hard coded to send the redirect to another domain, perhaps you could force it not to do that in the test environment. Maybe instead it could send you to a page within your domain that you could then test for using the browser.

Is all this a little bit of extra work? No doubt… but if you tease apart the fundamentals of good testing and application building you’ll find these are the same principles you use when writing good unit tests. It’s up to you to make an application easier to test. You need to expose seams that you can tap into so you balance the need for confidence and coverage with those that enable you to write fast performing, deterministic tests.

If you go a bit further out of the box you’ll realize that these are the same principles of why we even write automated tests that a robot could perform. Why not just have a human perform all these steps manually? Easy - it’s not scalable, its slow, and it’s expensive. All of these decisions are a trade off. We potentially lose some form of confidence (because a human has intuition) and we spend engineering resources writing tests, but we get a faster, more scalable system that can be run over and over again at low cost, and it can pivot and change better as the given system under test changes over time too. Creating these seams is the same answer - you invest a bit more time maybe up front designing a more testable system (since you’re likely introducing tests after the fact - a problem you likely would have avoided building the system with tests in mind) but the end result is better.

[asos-arun]

@brian-mann {“chromeWebSecurity”: false} does not work for me either . I want my test execution to not stop when javaScript error is thrown by application.