Set cookie domain prefixed with a dot

[LeungMichael]

Current behavior:

The problem I am having is that the website I am testing is hosted on www.something.com. The website is using cookies to avoid showing a popup multiple times. The cookie the website adds has a domain "www.something.com". I want to set this cookie when I start my test run so I don't get the popup.

When I use setCookie and pass it a domain "www.something.com", it actually adds a dot in the domain (.www.something.com). This causes the website to ignore this cookie and adds a duplicate cookie, without the dot before the domain.

Can I somehow force the setCookie to not alter my domain value?

Desired behavior:

The cookie domain to not be prefixed with a dot.

Steps to reproduce:

cy.setCookie('myCookie', 'true', { domain : 'www.something.com' })
cy.getCookie('myCookie').should('have.property', 'domain', 'www.something.com')

the assertion fails with ".www.something.com"

Versions

3.0.1
Windows 10
Chrome

[km333]

A couple of additional observations:

1. This also causes js-cookie cookies.remove('my-cookie') to silently not delete the cookie which is causing havoc in my tests (user does not get logged out, etc.)

2. localhost does not seem to be affected by this problem

[jennifer-shehane]

This is still an issue in Cypress 3.4.0.

Reproducible test

it('test 1', () => {
  cy.visit('https://example.cypress.io')
  cy.setCookie('myCookie', 'true', { domain: 'example.cypress.io' })
  cy.getCookie('myCookie').should('have.property', 'domain', 'example.cypress.io')
})

I also narrowed down that this is an issue with the setCookie and not the getCookie, since you can see that the actual cookie domain has the . prefix set in it.

[jennifer-shehane]

After further investigation - this is exactly how cookies work and are implemented within user agents. If you run this within the console - a . is prefixed to the domain that is set.

document.cookie = "test=Hello;domain=example.cypress.io"

Then go to the Application tab of your devtools, you will see the following cookie set, with the domain being .example.cypress.io

Cypress is simply passing along the domain information to the document.cookie as intended. This is not a bug, but exactly what happens within the browser itself.

Notably, as part of the cookies spec, leading . are ignored. https://tools.ietf.org/html/rfc6265#section-4.1.2.3

[chenfan-fchen]

same here, how do you resolved this?

[emil14]

Then go to the Application tab of your devtools, you will see the following cookie set, with the domain being .example.cypress.io

I don't see anything

[xumepadismal]

Hi @jennifer-shehane! Although this is indeed native browsers behavior there IS a possibility to set dot-less cookie by not specifying domain at all:

document.cookie = "test=Hello"

And this is what we can meet in real applications. By using cy.setCookie() we can't mimic this behavior and this can lead to this:

First cookie was set by PHP itself while second one by Cypress. One of those cookies is definitely outdated and wrong and you never know which one will be used by application.
Furthermore, real applications can have some technical subdomains which can also have their cookies set without leading dot.

Would it be possible to add some extra option to SetCookieOptions? Something like this:

cy.setCookie('test', 'value', {domain: 'example.com', domainExact: true})
cy.setCookie('test', 'value', {domain: 'api.example.com', domainExact: true})
cy.setCookie('test', 'value', {domain: 'static.example.com', domainExact: true})

And last but not least. I noticed that if my baseUrl is e.g. "docs.cypress.io" and I'm trying to cy.setCookie('test', 'value'); (without specifying domain) then cookie will be set to ".cypress.io" which is weird and not match browser behavior

[titchimoto]

Any updates on this issue? Having my tests fail in CI due to this prefixed . and it not setting the exact hostname.

[itsik-avidan]

Encountered this behavior as well.
We have cookies been set with the expectation to be available on sub-domains and defined using the 'leading-dot' while relying on RFC-6265
It seems that electron is failing to support this while major browsers does

[Songyu-Wang]

@xumepadismal I totally agree with what you said above. However, since this is a closed issue, I don't know if Cypress team will see this and act on it. Could you just open a new issue for this to grab their attention?

I think the main point in this issue is that Cypress set domain with a dot, but the issue we are concerning is that Cypress cannot accommodate dotless application domain which happens in real world

OR

cc @jennifer-shehane and see if she can re-evaluate the issue

[xumepadismal]

@Songyu-Wang There is already an open issue #16856 to track this

[Songyu-Wang]

Ah thank you @xumepadismal