Cypress: Incorrect document.domain

[ghengeveld]

Current behavior:

When running Cypress against a subdomain (e.g. sub.example.com), document.domain is reported as example.com.

Desired behavior:

document.domain should be the full domain name sub.example.com.

Steps to reproduce:

Run a Cypress test against a subdomain:

cy.visit("https://en.m.wikipedia.org/wiki/Main_Page")

Then run document.domain in the dev console. Expected output: "en.m.wikipedia.org".

Versions

Latest Cypress using Chrome Canary.

[brian-mann]

This is the correct behavior. I'm not sure why you're asking for it to be different. Setting document.domain to the superdomain is what is intended so that subdomains do not break origin policy. Otherwise they would be considered cross origin frames.

[ghengeveld]

It's inconsistent with normal browser behavior. In my case it breaks my app. Luckily I can emulate it using location.href instead:

const domain = document.location.href.match(/\/\/([^:/]+)/)[1]

Since I have a workaround, I can live with the inconsistency, but maybe it's worth reconsidering this behavior.

[jennifer-shehane]

I also do not believe this to be correct behavior. If you manually visit "https://en.m.wikipedia.org/wiki/Main_Page" and do document.domain in the console - it prints en.m.wikipedia.org which is NOT what it returns within Cypress.

Failing reproducible example:

it('document.domain not right', function () {
  cy.visit('https://en.m.wikipedia.org/wiki/Main_Page')
  cy.document().its('domain').should('eq', 'en.m.wikipedia.org')
})

[turkeyzawa]

Is there any progress being made on this issue? This behavior makes our app broken because we use document.domain in the javascript to call our backend's apis.

[jennifer-shehane]

This issue is still in the 'ready for work' stage, which means no work has been done on this issue as of today, so we do not have an estimate on when this will be delivered.

[nicojs]

@jennifer-shehane are you open to a PR for this issue? If so, could you point potential first time committers in the right direction?

I would propose being able to override the default behavior of using the "superdomain", instead letting users use the sub-domain and thus accepting the limitation of not being able to visit other (sub-)domains.

[tdelphi]

I also run into this bug.
In my case – my app is using OWASP CSRFGuard with pretty strict configuration and JS protection. Which blocks every request that does look suspicious.
So, when my app is running on internal domain https://myPc.domain1.domain2.com but cypress changes each document.domain to domain2.com, then OWASP CSRFGuard stops injecting CSRFToken into HTML forms, and after that every single request leads to “we are getting hacked” page of my app.
As a possible solution - it would be sufficient for me to be able to hard-code desired domain inside tests.

[nicojs]

Yeah, i think document.domain is a pretty big side effect. I'm trying for a couple of days to make it work but simply cannot. However, I don't feel inclined to fix it without an "approval" of a Cypress core contributor.

[jennifer-shehane]

We reviewed this as a team and have decided that while this is unexpected behavior, we won't be changing this behavior in Cypress today.

With the way Cypress works today, we have to set the document.domain in this way to avoid issues with visiting other subdomains. If this is causing problems within your testing, we suggest updating your application code, so that when visiting during testing, within a testing environment, it removes any limitations around the document.domain issue.

To more directly address @tdelphi, in this case, from the information you provided, we would recommend turning off the OWASP CSRFGuard restrictions during testing.

A simple way to check if your application is running while being visited within Cypress can be found here. I'd suggest a combination of detecting Cypress and also knowing that the tests are being run from within your own development team - then changing the application logic in this instance.

@nicojs I'm not sure about the issue you are encountering exactly, since you never described it, so let us know if there is some limitations to our suggestion.

We're always welcome to reconsider fixing this or offering a better workaround or errors in the future. So, please comment if you have objections to our suggestion.

[nicojs]

Thanks for your response.

@nicojs I'm not sure about the issue you are encountering exactly, since you never described it, so let us know if there is some limitations to our suggestion.

Our (single page) application is loaded from a CMS in a big enterprise company. It also loads a lot of 3rd party JavaScript from different domains. The 3rd party scripts are used to load a chat application, a cookie consent form, stuff like that. The 3rd party JavaScript determines which additional JavaScript to load dynamically from the main domain. The current way it does that is by adding script tags to the page with the src attribute pointing to files on the original domain. It does that by, you guessed it, using the infamous document.domain. It results in invalid urls which in turn makes it so that the page load event never occurs. Our test script fails with a timeout because the visit never finishes. We don't have direct control over the 3rd party scripts. I would like to see it differently, but we cannot change the way the entire organization works. I've seen these practices in more enterprise organizations, so I don't feel like it is uncommon.

With the way Cypress works today, we have to set the document.domain in this way to avoid issues with visiting other subdomains.

Like I stated earlier: I can understand this reasoning, however we don't need this feature in our use case. That's why I was proposing making this behavior optional.