Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redirected to chrome-error://chromewebdata/ when X-Frame-Options present on redirected domain #4220

Closed
gerardovanegas-eagle opened this issue May 16, 2019 · 142 comments
Labels
existing workaround prevent-stale mark an issue so it is ignored by stale[bot] type: bug

Comments

@gerardovanegas-eagle
Copy link

gerardovanegas-eagle commented May 16, 2019

Current behavior:

I get this screen when I try to access certain pages:
image

This I can easily access on the same browser used by cypress
image

I have my "chromeWebSecurity": false on my cypress file just in case

Desired behavior:

Continue executing the test. Access the pages that are completely accessible when not accessed through cypress' chrome

Steps to reproduce: (app code and test code)

This is my code, I hope this one is reproducible:

describe('Happy Path B2C / Checkout V2 ', function () {
beforeEach("Home - Catalog - PP - Cart", function(){

        //Going directly to product's page 
        cy.visit('https://juntozstagingv2.com/es-pe/');

        //Closing Ads
        cy.get("div[data-action='close-mc-modal']").click({force:true})

        //Triggerin Login
        cy.get("a[aria-haspopup='true']").click();
        cy.get("a[href='https://juntozstagingv2.com/account/login']").click();
    })
});

┆Issue is synchronized with this Jira Epic by Unito

@jennifer-shehane
Copy link
Member

Cypress cannot visit 2 superdomains within the same test. Although the href does equal juntozstagingv2, the url is redirecting to account.juntoz-staging.com upon click.

I would suggest taking a look at one of our recipes testing clicking into links with a different domain and restructuring your test to account for this.

@emijmker
Copy link

emijmker commented May 24, 2019

I have the same issue, it works in 3.2.0. After updating to 3.3.1 i now get this error as well.
Also have "chromeWebSecurity": false, yes working cross domain but didn't have the issue before the update.
image

@Vinod-Gulia
Copy link

I'm facing the same issue after upgrading cypress to cypress@3.4.0. Is there a solution found already?

@dave0688
Copy link

dave0688 commented Aug 1, 2019

Have exactly the same issue. Cypress looks nice, but if such "simple" things do not work it's hard to work with it.

@Sjeiti
Copy link

Sjeiti commented Sep 17, 2019

I would suggest taking a look at one of our recipes testing clicking into links with a different domain and restructuring your test to account for this.

We get the same error and we're on one superdomain. We are however using a subdomain for authentication.
The referenced solutions are specifically for other superdomains.

The last version that still worked for us was 3.2.0

When we install the latest Cypress (3.4.1) the tests run up until the first redirect (from https://bar.foo to https://login.bar.foo). It errors with the cross-origin error message.

When we add chromeWebSecurity:false to the settings we fail before redirecting to a subdomain with chrome-error://chromewebdata/ in the address bar and the following error stacktrace (failed trying to load):

Error: write EPROTO 101057795:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:c:\projects\electron\vendor\node\deps\openssl\openssl\ssl\s23_clnt.c:802:

    at _errnoException (util.js:1024:11)
    at WriteWrap.afterWrite (net.js:867:14)

Cypress 3.3.0 throws the same errors so something in that changelog should have caused it.

The one change that stands out are the proxy settings. We did find a proxy in the registry but adding it to HTTP_PROXY and HTTPS_PROXY simply causes the tests to fail altogether (a blank test page without the Cypress ui). Previously it failed after login.
We did suddenly get the message that Cypress couldn't verify the baseurl running (which is running).

Maybe it is not really a proxy issue ? (since we can login but the subdomain redirect fails)
We are running out of ideas here.

@pardonmeme
Copy link

Also got that issue, Our app is redirecting directly to our auth(which is a seperated domain) if user is not logged in and then redirects back to the app. But it seems like it just shows that chrome-error://chromewebdata/

:/

@chhiragkataria
Copy link

We are facing the same issue - on 3.4.1 and see chrome-error://chromewebdata/
Has anyone found a workaround?
Why is the cypress team not looking into it?

@gastonmorixe
Copy link

Same
image

@soomro12
Copy link

Same issue we are facing. Any solution??

@PrinceSoni83
Copy link

I also have the same issue with chrome Version 78.0.3904.108

@as001622
Copy link

It seems related to chromium version, after installing chrome Version 78.0.3904.108-1 I was available to run tests without that error.

@adomyaty55foundry
Copy link

adomyaty55foundry commented Dec 10, 2019

Reporting in, I'm having this same issue and would love for Cypress to better handle/solve this. It's an annoying one especially when testing OAuth2 and other stuff that requires domain changing. These things are common nowadays and we should account for allowing us to test such cases.

@JasonTheAdams
Copy link

JasonTheAdams commented Jan 22, 2020

Same issue here while using the same superdomain. The tests work locally, but when running on CircleCI we're running from http://localhost:8000. The page redirects to http://app.localhost:8000 after login is successful. This is when the error happens.

Turns out that our issue had to do with the domains not resolving properly in the container. I did some dnsmasq work and that resolved the issue. In short, we're using actual domains (not localhost) in our CircleCI tests now and set up a dnsmasq wildcard to catch everything for the domain.

@gmbarroso
Copy link

gmbarroso commented Jan 24, 2020

@jennifer-shehane is there any updates where it will be possible to access more domains at the same test? Cause it seems a lot of people try this.

Me, for example, I can't open some modal in a table just because this modal verifies the user token to open it.

I'm keeping having this issue and it is really annoying.

Thanks

@webartdev
Copy link

Same issue here while testing Auth and other stuff that requires domain changing.

@JasonTheAdams
Copy link

I want to loop back and report that our issue was our own problem. I've updated my comment above.

@HumbertoF
Copy link

same issue here, it is very annoying! :(

@visuallization
Copy link

We are having the same issue on cypress 3.5.0 and "chromeWebSecurity": false set.

@jennifer-shehane
Copy link
Member

Unfortunately no one has provided enough information to reproduce the problem. This means that we do not have a path to move forward, so no, no progress has been made on this issue as we cannot see this error on our machines with no reproducible example.

Please comment in this issue with a reproducible example so we can begin addressing the issue.

@jennifer-shehane jennifer-shehane added the stage: needs information Not enough info to reproduce the issue label Feb 4, 2020
@khitrenovich
Copy link

Can this be a duplicate of #1506 maybe?

@AlexanderHritsun
Copy link

AlexanderHritsun commented Feb 11, 2020

Good day everyone! I have the same issue and wanna describe how I fixed it.

Application features:

  1. We have the main domain - https://condogenie-app and can create "accounts" from it. Every account has own subdomain for example: https://staging.condogenie-app where "staging" is the unique account name
  2. To create a new account we are navigating to https://condogenie-app/account-sign-up.
    On this page, we set the account name and click the 'Finish' button. After this action system navigates us to subdomain page: https://staging.condogenie-app/account-sign-up-finish
    Exactly on this step, the issue arises.

Strangeness:

  1. The issue started to reproduce one week ago before it no problems occurred
  2. If "chromeWebSecurity": true - cypress shows 'cross-origin security' error
  3. If "chromeWebSecurity": false- we get chrome-error://chromewebdata/ and the cypress runner crashed

How I fixed it:
It was surprising for me, but no error arises for my old code(which was written several weeks or months ago). So I started comparing new and old code and couldn`t find any differences. That why I decided to copy the old code to the new file(it is working). After that I started to delete parts of the old code and found that the issue arises if we change the variables names!
Example of variables with which tests passed:

export const renterEmail = 'renter4booking@example.com';
export const renterFname = 'Renter';
export const renterLname = 'Book';
export const accountName = `bookings${Date.now()}`; 

Example of variables with which tests failed:

export const accountName = `bookings_tests${Date.now()}`;
export const renterEmail = 'renter4bookings@example.com';
export const renterFname = 'Renter';
export const renterLname = 'Bookings';

I can`t explain this strange behavior. I tried to change variables import order but it changes nothing. Besides, if I write a new code it will be crashed.
Hope this information will help you in the issue investigation

@visuallization
Copy link

Good day everyone! I have the same issue and wanna describe how I fixed it.

Application features:

  1. We have the main domain - https://condogenie-app and can create "accounts" from it. Every account has own subdomain for example: https://staging.condogenie-app where "staging" is the unique account name
  2. To create a new account we are navigating to https://condogenie-app/account-sign-up.
    On this page, we set the account name and click the 'Finish' button. After this action system navigates us to subdomain page: https://staging.condogenie-app/account-sign-up-finish
    Exactly on this step, the issue arises.

Strangeness:

  1. The issue started to reproduce one week ago before it no problems occurred
  2. If "chromeWebSecurity": true - cypress shows 'cross-origin security' error
  3. If "chromeWebSecurity": false- we get chrome-error://chromewebdata/ and the cypress runner crashed

How I fixed it:
It was surprising for me, but no error arises for my old code(which was written several weeks or months ago). So I started comparing new and old code and couldn`t find any differences. That why I decided to copy the old code to the new file(it is working). After that I started to delete parts of the old code and found that the issue arises if we change the variables names!
Example of variables with which tests passed:

export const renterEmail = 'renter4booking@example.com';
export const renterFname = 'Renter';
export const renterLname = 'Book';
export const accountName = `bookings${Date.now()}`; 

Example of variables with which tests failed:

export const accountName = `bookings_tests${Date.now()}`;
export const renterEmail = 'renter4bookings@example.com';
export const renterFname = 'Renter';
export const renterLname = 'Bookings';

I can`t explain this strange behavior. I tried to change variables import order but it changes nothing. Besides, if I write a new code it will be crashed.
Hope this information will help you in the issue investigation

Thank you for taking the time to report this here! That's a strange issue indeed. Let's hope cypress team has some ideas.

@anveshpuli
Copy link

Facing the same issue , tried setting the cookies SameSite = none but haven't got any better results . Looking forward to hear back soon!!

@XiangyangShi
Copy link

Reporting in, similar with adomyaty55foundry@

My website is for internal use and I use Cypress for testing OAuth2.
[tab_handling_anchor_links_spec.js] doesn't help since the login button will contains lots redirects and the middle station is within another Authorizer domain we own. These things are common use cases nowadays.

@jennifer-shehane
Copy link
Member

Unfortunately no one has provided enough information to reproduce the problem. This means that we do not have a path to move forward, so no, no progress has been made on this issue as we cannot see this error on our machines with no reproducible example.

Please comment in this issue with a reproducible example so we can begin addressing the issue.

@pshynin
Copy link

pshynin commented Mar 10, 2020

to reproduce the problem you really need to click the link with external resource like itunes, google play store, amazon etc..
test will look like this example provided by cypress team: https://github.com/cypress-io/cypress-example-recipes/blob/master/examples/testing-dom__tab-handling-links/cypress/integration/tab_handling_anchor_links_spec.js#L74

Since Cypress does not support switching between tabs, we need to make it open in current tab resetting href attribute to default _target value by removing it entirely:

.invoke('removeAttr', 'target')

or by setting it to _self :

.invoke('attr', 'target', '_self')

then source will be opened in current tab and another problem will appear as described in this ticket:

(NEW URL)
chrome-error://chromewebdata/
URL
ASSERT
expected chrome-error://chromewebdata/ to include google.com

as you can see I expected cy.url().should('include', 'google.com'); but instead url was chrome-error://chromewebdata/

Example of button to click:

<a href="https://play.google.com/store/apps/details" test-id="google-play" target="_blank">

Example of test verification:

cy.get('[test-id="google-play"]').invoke('attr', 'target', '_self').click();
cy.url().should('include', 'google.com');

PS: I also tried exporting HTTP_PROXY but this did not work either and is really overkill especially in case where we have many links to test.

hopefully this is something cypress team willing to implement sooner

@jennifer-shehane
Copy link
Member

@Tay08 No, the issue will be closed and a comment will be made if it is part of a release.

@davidfurlong
Copy link

davidfurlong commented Jun 29, 2021

I'm experiencing this issue with only different subdomains in one test (http://www.lvh.me:3000 & http://www_xyz_com.wl.lvh.me:3000) which should be fine as per https://docs.cypress.io/guides/references/trade-offs#Same-origin "chromeWebSecurity": false is set

@ghost
Copy link

ghost commented Aug 5, 2021

Hi @jennifer-shehane the fix is it included into v8.2.0?

@jennifer-shehane
Copy link
Member

@Tay08 No, the issue will be closed and a comment will be made if it is part of a release.

@StingyJack
Copy link

Please comment in this issue with a reproducible example so we can begin addressing the issue.

@jennifer-shehane - since this is happening during auth sequences, I doubt that very many are going to be willing or able to share the details you are asking for in a publicly visible GitHub issue. However, you should be able to setup a repro by having different subdomains

login.exampledomain.com - hosts the login page with a username/password credential
sts.exampledomain.com - after user submits valid credentials they are redirected to here to receive a secure token
app.exampledomain.com - after the token is received, the user is redirected here to use the program they logged in to .

Cypress breaks for me starting at the STS step. There isnt any new windows or tabs being launched, or any popups, etc. Just one browser tab with some redirects. Electron works fine. its just chrome that shows the chrome-error://chromewebdata and the blocked extension message.

@DevPerers
Copy link

I also face the same problem, but its was solved by updating "cypress.json" according to @Jessica-Jiang-92

@ivandjorgon
Copy link

@DevPerers @Jessica-Jiang-92 How do we update "cypress.json"?

@DevPerers
Copy link

@DevPerers @Jessica-Jiang-92 How do we update "cypress.json"?
Just added following code line to your "cypress.json"
"chromeWebSecurity": false

@stefanseeger
Copy link

Might be interesting to you:
SSO redirect works for us on MacOS, but it does not on Windows with a company managed Chrome.
Maybe someone else can give their input for it.

@bunge12
Copy link

bunge12 commented May 26, 2022

After upgrading to v 9.7.0 and making use of cy.session and cy.origin, and following these guides (guide 1, guide 2), I am still unable to implement a login command with Auth0 that runs in CI. The command runs locally, however, when running in CI (Github Actions) I get the The command was expected to run against origin https://auth0.com but the application is at origin chrome-error://chromewebdata. error.

Here is the command I have so far:

Cypress.Commands.add('loginAsUser', (email, password) => {
	const args = { email, password };
	cy.session(args, () => {
		// visit homepage
		cy.visit('/');
		cy.get('button[data-cy=login]').click();
		// redirects to Auth0
		cy.origin('AUTH0 DOMAIN', { args }, ({ email, password }) => {
			cy.get('#username').type(email);
			cy.get('#password').type(password);
			cy.get('button')
				.contains(/^Continue$/)
				.click();
		});
		// assert we've returned to the site
		cy.url().should('contain', '/carousel');
	});
});

@Keenan144
Copy link

After upgrading to v 9.7.0 and making use of cy.session and cy.origin, and following these guides (guide 1, guide 2), I am still unable to implement a login command with Auth0 that runs in CI. The command runs locally, however, when running in CI (Github Actions) I get the The command was expected to run against origin https://auth0.com but the application is at origin chrome-error://chromewebdata. error.

Here is the command I have so far:

Cypress.Commands.add('loginAsUser', (email, password) => {
	const args = { email, password };
	cy.session(args, () => {
		// visit homepage
		cy.visit('/');
		cy.get('button[data-cy=login]').click();
		// redirects to Auth0
		cy.origin('AUTH0 DOMAIN', { args }, ({ email, password }) => {
			cy.get('#username').type(email);
			cy.get('#password').type(password);
			cy.get('button')
				.contains(/^Continue$/)
				.click();
		});
		// assert we've returned to the site
		cy.url().should('contain', '/carousel');
	});
});

So you can use Auth0's api to fetch your token and set the cookie. This is how I got around this issue with Auth0

Cypress.Commands.add('login', () => {
  Cypress.log({
    name: 'loginViaAuth0',
  });

  const options = {
    method: 'POST',
    url: Cypress.env('auth_url'),
    body: {
      username: Cypress.env('auth_username'),
      password: Cypress.env('auth_password'),
      realm: 'CypressE2E',
      grant_type: 'http://auth0.com/oauth/grant-type/password-realm',
      audience: Cypress.env('auth_audience'),
      scope: 'openid profile email',
      client_id: Cypress.env('auth_client_id'),
      client_secret: Cypress.env('auth_client_secret'),
    },
  };
  
  cy.request(options);
});

The response will include the session and JWT you need.

@bunge12
Copy link

bunge12 commented Jun 8, 2022

@Keenan144 I have tried this approach, but instead of setting the cookie I needed to set localStorage since my Auth0 provider is set with cacheLocation="localstorage". It didn't work in CI as well while working perfectly on my local machine.

@Keenan144
Copy link

@bunge12 thats a bummer, the only other thing I could suggest is to make sure your ENV vars are being set correctly. With cypress you need to append CYPRESS_ to your variables in github actions.

@sfrendpax8
Copy link

@bunge12 I have the exact same issue, trying to login to auth0. Only fails on CI.

Did you come up with a fix?

@bunge12
Copy link

bunge12 commented Sep 26, 2022

@sfrendpax8 we decided to run Cypress on CircleCI instead of GitHub Actions and it runs without a hitch :)

@gowthammk
Copy link

gowthammk commented Dec 1, 2022

I am facing the same issue for some time now. My org has internal support to Cypress 8.3.0 as of today.

Interestingly my tests runs locally but when I push it to pipeline it fails. From the video recording it looks like initially it goes to https://beta.xxx.xxxx.xxxxxxx.xxx/ but within seconds it gets redirected to chrome-error://chromewebdata

My redirected url is in an iFrame element and I think that's what is causing the issue.

My configs and versions:
chromeWebSecurity: false
Cypress: 8.3.0
Browser: Chrome 107 (headless)

Anyone came with a fix?

@cooleiwhistles
Copy link

Are there any workarounds for the issue? I am facing this today using Cypress 12.7.0.
Test runs fine locally, but in Jenkins CI, I am redirected to chrome-error://chromewebdata/ once I launch my application.

@asrafmi
Copy link

asrafmi commented Mar 27, 2023

sorry, your link cant be opened

@asrafmi
Copy link

asrafmi commented Mar 27, 2023

Are there any workarounds for the issue? I am facing this today using Cypress 12.7.0. Test runs fine locally, but in Jenkins CI, I am redirected to chrome-error://chromewebdata/ once I launch my application.

we're on the same boat, but im using drone. My code passed all the test in local but got an error in Drone

@nagash77 nagash77 added the prevent-stale mark an issue so it is ignored by stale[bot] label Apr 3, 2023
@jaredtbates

This comment was marked as resolved.

@nagash77
Copy link
Contributor

nagash77 commented May 4, 2023

@jaredtbates have you gone through our Auth0 Guide?

Also, check out our community chat, it can be helpful for debugging or answering questions on how to use Cypress.

@jaredtbates

This comment was marked as resolved.

@jaredtbates

This comment was marked as resolved.

@nagash77
Copy link
Contributor

nagash77 commented May 5, 2023

@jaredtbates glad you got it figured out! I am going to close this old issue since much has changed since the release of cy.origin. If folks have issues in the latest version of Cypress please open a new issue and we will be happy to investigate.

@nagash77 nagash77 closed this as completed May 5, 2023
@geyuqiu
Copy link

geyuqiu commented May 8, 2023

For us, we got it running with

  • CAS that stands between the frontend/Backend app and the Microsoft authentication server (login with Microsoft)
  • node 14.x.x (node with later version does not work because of the chrome-error://chromewebdata)
  • localhost going against a CAS server on a different host on dev environment
  • cy.origin
  • clearing session storage and cookies before login in cypress tests

@corentinguilloux
Copy link

corentinguilloux commented Feb 1, 2024

Hi everyone,

We are also facing the issue right now with cypress 13.0.0 and Node 20.10.0

We've got an Angular 17 application that uses Keycloak for OIDC connection. When opening our app, the user is automatically redirected to the Keycloak home page for connection. It works fine when hand testing but when using Cypress the automatic redirection cannot be done and we got the chrome-error://chromewebdata/ page.

Here is my code (for local test) with baseUrl:"http://localhost:4200" and chromeWebSecurity: false. I tried clearing cookies and session storage and it doesn't change anything

    cy.visit('/'); // auto redirect when visiting our site
    cy.origin('http://localhost:8080', () => {
      cy.url().should(
        'include',
        '/auth/realms/agritrust/protocol/openid-connect/auth?client_id=agri-consent-portal-frontend' // keycloak redirection url
      );
    });

In the cypress navigator web console, we can see the keycloak auth request but it fails

fetch("http://localhost:8080/auth/realms/agritrust/protocol/openid-connect/auth?client_id=agri-consent-portal-frontend&redirect_uri=http%3A%2F%2Flocalhost%3A4200%2F&state=10104a3b-5221-414f-aa0a-3e5f26fc7cb7&response_mode=fragment&response_type=code&scope=openid&nonce=d90f0d4b-7c42-4e97-832b-aa0750dfd383&prompt=none&code_challenge=kHDeVEtRERsRyQn_v7Of84xDF0lzRd9RN5UfhTGVBBI&code_challenge_method=S256", {
  "headers": {
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7",
    "accept-language": "fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7",
    "proxy-connection": "keep-alive",
    "sec-ch-ua": "\"Not A(Brand\";v=\"99\", \"Google Chrome\";v=\"121\", \"Chromium\";v=\"121\"",
    "sec-ch-ua-mobile": "?0",
    "sec-ch-ua-platform": "\"Windows\"",
    "sec-fetch-dest": "iframe",
    "sec-fetch-mode": "navigate",
    "sec-fetch-site": "same-site",
    "upgrade-insecure-requests": "1",
    "x-cypress-is-aut-frame": "true"
  },
  "referrer": "http://localhost:4200/",
  "referrerPolicy": "strict-origin-when-cross-origin",
  "body": null,
  "method": "GET",
  "mode": "cors",
  "credentials": "include"
});

If you've got any clue I'll take it, thanks

@jennifer-shehane jennifer-shehane removed the stage: needs investigating Someone from Cypress needs to look at this label Feb 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
existing workaround prevent-stale mark an issue so it is ignored by stale[bot] type: bug
Projects
None yet
Development

No branches or pull requests