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

Interatomic

You can verify if cookie is being set in the "Resources" tab - i.imgur.com/4W57ztA.png . If it's not, we'll need a tool to validate headers that you are sending. – Inspection

I've verified the cookie wasn't sent in the Network Tab under the post request's headers. But, the cookie isn't event set under the Resources Tab. – Interatomic

Answer 1

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).

Interatomic

Yet when I use Incognito Mode or a different Chrome profile it works. So I'm confused why this is only an issue in my normal Chrome profile. – Matney

Answer 2

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:

Entreaty

thanks man, I was looking for this from 3 days. – Aground

On problematic requests, I'm finding that the Cookies tab does not appear. – Fevre

@Fevre This might help you: https://mcmap.net/q/374254/-chrome-network-request-does-not-show-cookies-tab-some-request-headers-copy-as-curl-is-broken. Though the answer there didn't work for me. – Entreaty

Thanks Lucas! I couldn't find the issue for couple of hours. I didn't know about this option in chrome. – Dennisedennison

Unfortunately, this does not show blocked third-party cookies. The default setting in chrome is block third-party cookies in incognito, so if you're testing in incognito this is probably why your cookies aren't being sent. – Byram

Answer 3

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));

Dipnoan

Answer 4

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.

Provenience

This works in Firefox, and that's not how it it's supposed to work. At least according to this post. The useragent is supposed to "supply" the dot, so it's written as .dev which should submit the cookie on dev and any subdomains of dev. – Interatomic

Answer 5

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.

Cuspidation

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.

Ecclesiastes

Answer 7

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.

Cory

Answer 8

As of 2022 in Chrome...

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

Anew

Answer 9

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.

Erny