Set cookie domain prefixed with a dot
See original GitHub issueCurrent 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
Issue Analytics
- State:
- Created 5 years ago
- Reactions:20
- Comments:11 (6 by maintainers)
Top Results From Across the Web
What does the dot prefix in the cookie domain mean?
The leading dot means that the cookie is valid for subdomains as well; nevertheless recent HTTP specifications (RFC 6265) changed this rule ...
Read more >Set-Cookie - HTTP - MDN Web Docs
The Set-Cookie HTTP response header is used to send a cookie from the server to the user agent, so that the user agent...
Read more >Cookie domain with dot in front
When setting a domain in the cookie, the safe choice is to have it preceded by a dot, like.erik.io. The cookie will match...
Read more >Leading Dots On HTTP Cookie Domains Ignored - Ben Nadel
Leading Dots On HTTP Cookie Domains Ignored ... Defines the host to which the cookie will be sent. If omitted, this attribute defaults...
Read more >drop the prefixed dot in cookie domains (#125) · Issues - GitLab
RFC 2965, the old cookies specifications, states that if the Domain attribute in the Cookie header field doesn't start with a dot character,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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:
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: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 behaviorsame here, how do you resolved this?