← Back to libraryQuestion 184 of 468
🌲CypressAdvanced

Handling Multiple Domains with cy.origin

📌 Definition:

By default Cypress restricts a test to a single superdomain for security. cy.origin lets a test execute commands on a DIFFERENT origin (e.g. a third-party auth/SSO or payment domain) within the same test.

📖 Detailed Explanation:

Historically, visiting a second domain in one test threw a cross-origin error. cy.origin('https://auth.example.com', () => { /* commands run here */ }) runs a block of Cypress commands in the context of another origin, enabling SSO/OAuth login flows and redirects to external providers. Variables from the outer scope must be passed explicitly via the args option because the callback runs in a separate context. Even with cy.origin, prefer bypassing third-party UIs when possible (programmatic login) for speed and reliability; use cy.origin when you genuinely must drive the external domain.

🔑 Key Points:
  • cy.origin runs commands on a different origin (SSO, payment, redirects)
  • Pass outer variables via the { args } option (separate context)
  • Enables OAuth/SSO flows that used to throw cross-origin errors
  • Still prefer programmatic login over driving third-party UIs when feasible
🌍 Real-World Example:

Testing 'Login with Google': cy.origin('https://accounts.google.com', { args }, ({ email }) => { cy.get('#email').type(email); ... }) drives the Google page, then control returns to the app origin to assert the logged-in state.

🎯 Scenario-Based Interview Question:

A test that redirects to an external SSO provider fails with a cross-origin error. What's the modern Cypress solution and its gotcha?