max 1 site... support visiting multiple superdomains in one test

[jukefr]

"One thing you may notice though is that Cypress still enforces
visiting a single superdomain with cy.visit().
This is an artificial limitation (and one that can be removed).
You should open an issue and tell us what you’re trying to do!"
- https://docs.cypress.io/guides/guides/web-security.html#Disabling-Web-Security

I was trying to get a quick script to press an update button on 500 of our domains.

Maybe you could document a way for us to remove this limit without having to open an issue to have the core functioning of the app changed ? Maybe allow passing an argument when running the app.

[brian-mann]

Yeah, it can be done. Quick question - is there any reason you need a browser to load up 500 different domains and click a button?

Wouldn't it be much much easier to just use cy.request or another programatic means to accomplish this?

For instance, what does clicking the button do? Send an HTTP request is my guess. So instead of using the UI, just send the HTTP request directly using cy.request. Same result, 100x faster, and no domain issues.

Any additional information about your use case would be helpful.

[ejoubaud]

Just jumping in to say that I have a use-case where I need to load several sites in the same test (not 500, 2 will do for a test).

I'm testing a browser extension that will show a modal (via a content script) on several sites that you can whitelist in its settings. The extension uses a global timer (via its background tab) to synchronise the extension's behaviour across different sites/tabs/link clicks/refreshes (it persists a countdown as you browse those various whitelisted sites, among other things). Because of this restriction, I can't test that the synchronisation works when the sites I visit are on different domains.

I can't just make a cy.request because I need Chrome to load the page, then load the extension's contentscript on it, then assert that the contentscript shows the modal and that its content is coherent with the cross-tab synchronisation I expect to happen.

[MaxwellGBrown]

Wouldn't it be much much easier to just use cy.request or another programatic means to accomplish this?

To me the issue is that it is more work to simulate the requests than it is to have Cypress fill in a form.

That and it deviates too far from the User flow that my users would be experiencing.

[alovato88]

This is an applicable issue for my organization's test code. We recently implemented OKTA, which requires you to go to a super domain to authenticate then route to the super domain that is going to be tested. When I use "cy.visit()" after authenticating, all authentication data will be wiped out and Cypress will attempt to authenticate the same exact way again, causing either a sid or cross domain error. Due to this issue, we are about to drop Cypress all together and move back to Selenium.

[brian-mann]

@alovato88 if you switched to using cy.request to programmatically log in to receive your token, everything would just work. We have multiple recipes showcasing this.

@MaxwellGBrown we've been down this rabbit hole many times with many different user feedback and the answer is always the same - you can test your login page in isolation away from the main app once, and then use cy.request to programmatically use it afterwards. You get the benefit of "really testing it like a user" and then once that is done you get no further benefit.

Just visit the OTHER domain in the test and log in. You could even stub the network request if you wanted to prevent the 3rd party server from redirecting you. Once you do that, then use cy.request to programmatically receive the token and then START with the token in hand visiting your real app. Just set the token directly in cookies or localstorage and your app will "start" logged in.

There are many other issues in here in which I've commented providing different approaches and work arounds you all may find useful.

Our best practices cover this pretty in depth, and I've even given a talk about this subject and provide real world examples of how to approach this problem.

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

@ejoubaud You can do this in Cypress - simply visit the domains in different tests, not the same test. As long as you don't visit two different super domains in one test it will all just work. Visit one super domain, test your extension, and then in a separate test visit a different one and test your extension in there.

[alovato88]

@brian-mann Where can I find any of these showcased recipes?

[brian-mann]

https://on.cypress.io/recipes

[dchambers]

I think I have a good use case for this. We're migrating from a monolithic Ruby on Rails app, to micro-services on the back-ends and user-type differentiated front-ends. Our new front-ends are React SPAs, and one of them is way too big to replace at once, so for some app routes we just display the original page within an iframe whereas for others we're using React components to render those routes.

At present I can't write tests that exercise new and old at the same time. I'm presently working around this by putting every test in its own file, but this is far from ideal.

[e-e-e]

We also require this functionality to test a third party integration

[tobocop]

I would love to be able to visit multiple domains. My use case is testing the integration between a front end site and a backend admin. There are certainly ways around not visiting multiple domains, however locally they are only running on different ports (3000, and 3001). There certainly are work arounds:

1. Using cy.request. I could do this however I'd be making requests to the backend api to seed users and make changes. If the API shape changes now my integration suite changes as does my application code. It seems like a strange coupling that I'd rather not have
2. Setting up a local apache to forward subdomains to the ports. Again. totally possible, however more complicated dev machine setup is something I'd rather avoid, especially since the different is only on port number and not on the hostname.

[duncan-bayne]

This is an absolute blocker for my current client. They have built a solution that integrates several SaaS systems including Salesforce, and need to be able to test side-effects in integrated systems. For example, that registering in the Web front-end causes a lead to be created in Salesforce.

We too will have to abandon Cypress for Selenium, despite significant enthusiasm for Cypress, if this use case can't be addressed.

Update: maybe not ... we are able to subsequently test state on the SaaS system in a second context, and reset it in a third. Something of a hack though.

[jukefr]

As this has not been addressed properly for almost a year, I would advise (only my opinion) people who think Cypress is too restrictive to simply use Puppeteer directly (with a framework like Jest if needed).

Same result but with tools that are actively maintained and improved upon.

[alexander-veshkin]

w8ing this too.