21

I'm testing a web app that integrates Gmail, Slack, Dropbox etc. I'm trying to write end to end tests with Cypress.io to verify that auth flows are working. Cypress restricts me from navigating outside my app's domain and gives me a Cross Origin Error. The Cypress docs say that testing shouldn't involve navigating outside your app. But the entire purpose of testing my app is to make sure these outside auth flows are functioning.

The docs also say you can add "chromeWebSecurity": false to the cypress.json file to get around this restriction. I have done this, but am still getting cross origin errors (this is at the heart of my question. I would ideally get around this restriction).

I have attempted cypress' single-sign-on example. https://github.com/cypress-io/cypress-example-recipes#logging-in---single-sign-on I was not able to make it work, and it's a lot more code than I think is necessary.

I've commented on this thread in github, but no responses yet.

Full error message:

Error:     CypressError: Cypress detected a cross origin error happened 
on page load:

  > Blocked a frame with origin "https://www.example.com" from 
accessing 
    a cross-origin frame.

    Before the page load, you were bound to the origin policy:
      > https://example.com

A cross origin error happens when your application navigates to a new 
superdomain which does not match the origin policy above.

This typically happens in one of three ways:

1. You clicked an <a> that routed you outside of your application
2. You submitted a form and your server redirected you outside of your 
application
3. You used a javascript redirect to a page outside of your application

Cypress does not allow you to change superdomains within a single test.

You may need to restructure some of your test code to avoid this 
problem. 

Alternatively you can also disable Chrome Web Security which will turn 
off this restriction by setting { chromeWebSecurity: false } in your 
'cypress.json' file.

https://on.cypress.io/cross-origin-violation
Bill Mayo
  • 349
  • 1
  • 2
  • 8
  • I assume you are going to a 3rd party superdomain that is not under your control. If this is true then you should not be navigating to that page in cypress, and there could be a few reasons why it's breaking – kuceb May 25 '18 at 14:33
  • 2
    In some scenarios people are going to have applications that are protected by Sign-in that is out of their control and off domain. For example we have an authentication flow that can't be circumvented by just POSTing to the Slack Oauth endpoints. In this scenario, whilst not ideal, it's preferable to be able to navigate Cypress to another domain and sign-in. Rather than repeat the docs' purist view of "don't do this" it would be useful to help towards a workaround. – Tom Aug 19 '19 at 16:37
  • @Bill Mayo did you ever find a solution to this? The error message implies your cypress.json isn't being picked up. – Tom Aug 19 '19 at 16:39
  • I have this same problem -- trying to authenticate with Slack. I wonder if making some kind of stub for the 3rd party server is what needs to happen here. Seems like this would require more work, but maybe it's the best practice. Anyways, Cypress has an example for logging in with a 3rd party server, which says: > Login when authentication is done on a 3rd party server. https://github.com/cypress-io/cypress-example-recipes/tree/master/examples/logging-in__single-sign-on – RancheroBeans Dec 06 '19 at 23:38

4 Answers4

6

setting { "chromeWebSecurity": false } in my 'cypress.json' file worked for me

Kiran Dash
  • 4,816
  • 12
  • 53
  • 84
  • 2
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Nov 16 '21 at 11:22
  • The `json` key should be in quotes `{ "chromeWebSecurity": false }` – Ram V May 03 '22 at 09:52
  • [This answer](https://stackoverflow.com/a/71277156/17865804) might also help. – Chris Oct 17 '22 at 10:16
  • @RamV Many keys are not in quotes why? Like `pageLoadTimeout: 5000` – paul Mar 09 '23 at 07:27
  • @paul Valid JSON must have double-quoted strings as keys. You've likely seen plain JS with data structures without the quotes. – jezmck Apr 19 '23 at 14:50
4

If you are trying to assert the proper navigation to gmail...

You should stub the function that handles that and assert that the request contains the necessary key value pairs. Without more information on the intent of this test it is hard to give specific advice. It sounds like you would want to have a "spy"(type of test double).

Here is the documentation for spies: https://docs.cypress.io/guides/guides/stubs-spies-and-clocks.html#Stubs

If you are trying to verify the contents of the email

You will want to use a library to handle reading gmail. cy.task can be used to invoke JavaScript from an external library. This Medium article has a good write up on how to do this.

Medium article: https://medium.com/@levz0r/how-to-poll-a-gmail-inbox-in-cypress-io-a4286cfdb888

TL;DR of article

  • Setup and define the custom task(method) that will check gmail(uses "gmail-tester" in the example)
  • Use cypress to trigger the email(obviously)
  • Capture/define data(like email subject, dynamic link, email content)
  • Assert the data returned from gmail-tester is as expected

DON'T

Use the GMail UI in your test in an effort to avoid test flake (all UI testing has flakiness), and potential UI changes to the Gmail app that require updates to your test. The backend methods that gmail-tester uses are less likely to change overtime compared to the UI. You also avoid the CORS error.

Disabling cross-origin security, if you must...(eek bugs!)

If you must, add chromeWebSecurity: false to the cypress.json config file. Be sure to add it inside of the curly braces. There should only be one set of braces in that file.

NOTE: One cannot simply use cy.visit(<diffSuperDomain>); there is an open issue. Apparently this is a very difficult change to make in cypress.

One potential workaround is to only have one super domain per test. It should work if you set the chromeWebSecurity: to false and only have one domain per test(it block). Careful, as it opens you up to cascading failures as one test will rely on the next. Hopefully they fix this soon.

https://docs.cypress.io/guides/guides/web-security.html#Disabling-Web-Security

General Grievance
  • 4,555
  • 31
  • 31
  • 45
NANfan
  • 449
  • 3
  • 16
1

Since Cypress 9.6.0 you can set "experimentalSessionAndOrigin": true in cypress.json. This allows your tests to operate in multiple domains using the origin command. Example from the official blog:

it('navigates', () => {
  cy.visit('/')
  cy.get('h1').contains('My Homepage')
  cy.origin('www.acme.com', () => {
  cy.visit('/history/founder')
    cy.get('h1').contains('About our Founder, Marvin Acme') // 
  })
})

At that blog entry there are also examples how to use this to authenticate at another domain. Worked fine for me with Keycloak using both Chrome and Firefox.

Marcus
  • 1,857
  • 4
  • 22
  • 44
-4

There are a few simple workarounds to these common situations: Don’t click <a> links in your tests that navigate outside of your application. Likely this isn’t worth testing anyway. You should ask yourself: What’s the point of clicking and going to another app? Likely all you care about is that the href attribute matches what you expect. So make an assertion about that. You can see more strategies on testing anchor links in our “Tab Handling and Links” example recipe.

You are testing a page that uses Single sign-on (SSO). In this case, your web server is likely redirecting you between superdomains, so you receive this error message. You can likely get around this redirect problem by using cy.request() to manually handle the session yourself.

If you find yourself stuck and can’t work around these issues you can just set this in your cypress.json file. But before doing so you should really understand and read about the reasoning here.

// cypress.json

{
  "chromeWebSecurity": false
}
Suraj Rao
  • 29,388
  • 11
  • 94
  • 103
Kronhyx
  • 41
  • 5
  • 10
    This is just a copy paste from the docs and doesn't actually answer the original question which already mentions adding the chromeWebSecurity flag to the configuration file. – Tom Aug 19 '19 at 16:41