How to tell why a cookie is not being sent?

Question

I'm using chrome and I'm wondering if there is either an extension or a method to tell why a cookie is not being sent.

I have one request I'm making to http://dev/login and it's returning,

Set-Cookie:DevId=cffbc7e688864b6811f676e181bc29e6; domain=dev; path=/; expires=Tue, 16-Jun-2015 21:27:43 GMT

However, on a post to http://dev/Base/User/home/ I'm not sending the DevId cookie. I'd love to know why the cookie isn't being sent if anyone happens to know. But, moreover, I'd love to know how I can tell why and how to better debug this problem in the future.

Here are some requests, as captured from Chrome's Dev tools

So here is my response from /login (notice Set-Cookie header),

HTTP/1.1 200 OK
Date: Tue, 16 Jun 2015 19:57:43 GMT
Server: Apache
Pragma: no-cache
Cache-control: no-cache, max-age=0
Set-Cookie: DevId=cffbc7e688864b6811f676e181bc29e6; domain=dev; path=/; expires=Tue, 16-Jun-2015 21:27:43 GMT
Cache-Control: max-age=0
Expires: Tue, 16 Jun 2015 19:57:43 GMT
Keep-Alive: timeout=10, max=10
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/json; charset=ISO-8859-1

And here is my post to /Base/User/home/1 (notice no cookie),

POST /Base/User/home/ HTTP/1.1
Host: dev
Connection: keep-alive
Content-Length: 0
Origin: http://dev
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/43.0.2357.81 Chrome/43.0.2357.81 Safari/537.36
Content-type: application/x-www-form-urlencoded; charset=UTF-8
Accept: text/javascript, text/html, application/xml, text/xml, */*
X-Prototype-Version: 1.7.2
X-Requested-With: XMLHttpRequest
Referer: http://dev/user/1/home
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8

Answer 1

just go to your server side code and update cookie properties to: secure:true;

Answer 2

Add credentials: 'include' in a frontend API call.

Add credentials: true in cors config (backend).

Here is my set-up cookies option :

const options = {
  httpOnly: false,
  sameSite: "None",
  secure: true,
};

SameSite Attribute: Controls cookie transmission with cross-site requests to mitigate security risks.

Values

• None: No protection, cookies sent in all cross-site contexts.
• Lax: Balances security and usability, allows cookies with regular links, blocks in risky contexts.
• Strict: Maximum security, blocks cookies in all cross-site contexts.

The default value of the SameSite attribute differs with each browser, therefore it is advised to explicitly set the value of the attribute.

Secure Attribute: Ensures cookies are only sent over HTTPS, preventing their transmission over unencrypted HTTP to protect them from unauthorized access.

Answer 3

How to tell why a cookie is not being sent:

• Go to network tab, and click the request that is not being sent with your cookie.

• Go to the "Cookies" tab that just appeared.

• Check "show filtered out request cookies"

Then a little "i" label will appear next to the property that is preventing the cookie from being sent. You can hover over to see the detail:

Answer 4

As of 2022 in Chrome...

In the Developer Tools > Network Tab > Headers > Response you can see why cookies are not set.

Answer 5

In my case, it was because Fetch API doesn't send cookies unless credentials: "include" is given as an option.

fetch('API_ENDPOINT',{
  method: 'POST',
  credentials: 'include',
  body: JSON.stringify(some_json_obj)
})

Also, I had to configure the Node.js ( express.js ) backend CORS as follows.

const cors = require('cors')

const corsOptions = {
  origin: 'http://localhost:3000',
  credentials: true
}

app.use(cors(corsOptions));

Answer 6

I received this error when I was setting the cookie without ; path=/ specified in my cookie setting. My webserver was then routing certain request to my webserver at / and the cookie wasn't being set because it was only valid for /auth where I had set it originally.

Notice that Path above is "/auth", which is where it is valid for. after setting path in my cookie:

`nz_auth_jwt=${jwt}; path=/; expires=...` 

I saw my cookie in subsequent requests. And verified that the path in dev tools was being set correctly to be valid for all routes which is what I wanted in my case.

Answer 7

If you are on a cross domain request and using an XHR client (like the fetch API), be careful about the withCredentials parameter.

The XMLHttpRequest.withCredentials property is a Boolean that indicates whether or not cross-site Access-Control requests should be made using credentials such as cookies, authorization headers or TLS client certificates. Setting withCredentials has no effect on same-site requests.

Answer 8

The issue Evan Carroll links to for chromium (now redirects here: https://bugs.chromium.org/p/chromium/issues/detail?id=56211 ) seems relevant, and is marked as "Fixed". It is not very clear how, though.

I had issues with a host entry in /etc/hosts like this one:

127.0.0.1   local.app.service.tld

But after changing it to

127.0.0.1   app.localhost

it works as expected again. I think chrome would do well in issuing a little log notice about this, when it happens. Alas, it would save us all a great deal of grief.

Answer 9

The problem is this:

domain=dev;

Quoting from RFC 2945:

The value of the Domain attribute specifies the domain for which the cookie is valid. If an explicitly specified value does not start with a dot, the user agent supplies a leading dot.

So the web client will only send the cookie if the host address ends in .dev.

Try sending the cookie without the domain attribute.

Answer 10

This is a Chrome specific bug. No fix yet..

#56211 chrome.cookies fails for localhost domains

https://code.google.com/p/chromium/issues/detail?id=56211

May also want to read this question. It isn't specific to chrome like this question, but it is specific to localhost behavior (unlike this question).