Why is the browser not setting cookies after an AJAX request returns?

Question

I am making an ajax request using $.ajax. The response has the Set-Cookie header set (I've verified this in the Chrome dev tools). However, the browser does not set the cookie after receiving the response! When I navigate to another page within my domain, the cookie is not sent. (Note: I'm not doing any cross-domain ajax requests; the request is in the same domain as the document.)

What am I missing?

EDIT: Here is the code for my ajax request:

$.post('/user/login', JSON.stringify(data));

Here is the request, as shown by the Chrome dev tools:

Request URL:https://192.168.1.154:3000/user/login
Request Method:POST
Status Code:200 OK

Request Headers:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:35
Content-Type:application/x-www-form-urlencoded; charset=UTF-8
DNT:1
Host:192.168.1.154:3000
Origin:https://192.168.1.154:3000
Referer:https://192.168.1.154:3000/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.154 Safari/537.36
X-Requested-With:XMLHttpRequest

Form Data:
{"UserId":"blah","Password":"blah"}:

Response:

Response Headers:
Content-Length:15
Content-Type:application/json; charset=UTF-8
Date:Sun, 16 Mar 2014 03:25:24 GMT
Set-Cookie:SessionId=MTM5NDk0MDMyNHxEdi1CQkFFQ180SUFBUkFCRUFBQVRfLUNBQUVHYzNSeWFXNW5EQXNBQ1ZObGMzTnBiMjVKWkFaemRISnBibWNNTGdBc1ZFcDNlU3RKVFdKSGIzQlNXRkkwVjJGNFJ6TlRVSHA0U0ZJd01XRktjMDF1Y1c1b2FGWXJORzV4V1QwPXwWf1tz-2Fy_Y4I6fypCzkMJyYxhgM3LjVHGAlKyrilRg==; HttpOnly

Answer 1

OK, so I finally figured out the problem. It turns out that setting the Path option is important when sending cookies in an AJAX request. If you set Path=/, e.g.:

Set-Cookie:SessionId=foo; Path=/; HttpOnly

...then the browser will set the cookie when you navigate to a different page. Without setting Path, the browser uses the "default" path. Apparently, the default path for a cookie set by an AJAX request is different from the default path used when you navigate to a page directly. I'm using Go/Martini, so on the server-side I do this:

session.Options(session.Options{HttpOnly: true, Path:"/"})

I'd guess that Python/Ruby/etc. have a similar mechanism for setting Path.

See also: cookies problem in PHP and AJAX

Answer 2

@atomkirk's answer didn't apply to me because

1. I don't use the fetch API
2. I was making cross-site requests (i.e. CORS)

NOTE: If your server is using Access-Control-Allow-Origin:* (aka "all origins"/"wildcard origins"), you may not be able to send credentials (see below).

Setting withCredentials/credentials in browser/client request

As for the fetch API; CORS requests will need {credentials:'include'} for both sending & receiving cookies

For CORS requests, use the "include" value to allow sending credentials to other domains:

fetch('https://example.com:1234/users', {   
            credentials: 'include' 
})

... To opt into accepting cookies from the server, you must use the credentials option.

---

{credentials:'include'} is equivalent to xhr.withCredentials=true

In fact, checkfetch polyfill code (a Javascript implementation)

if (request.credentials === 'include') {
      xhr.withCredentials = true
 } 

As @haneSmitter says in the comments, if fetch is implemented natively by your browser, you don't need a Javascript polyfill, so use the appropriate value for fetch credentials property. fetch allows three values for { credentials:'...' } configuration ( "omit", "same-origin", or "include"), whereas xhr is only a boolean (two values: true or false). Read more at the fetch spec here

---

If you're using jQuery, you can set withCredentials (remember to use crossDomain: true) using $.ajaxSetup(...)

$.ajaxSetup({
             crossDomain: true,
             xhrFields: {
                 withCredentials: true
             }
         });

---

If you're using AngularJS, the $http service config arg accepts a withCredentials property:

$http({
    withCredentials: true
});

---

If you're using Angular (Angular IO), the common.http.HttpRequest service options arg accepts a withCredentials property:

this.http.post<Hero>(this.heroesUrl, hero, {
    withCredentials: true
});

---

As for the request, when xhr.withCredentials=true; the Cookie header is sent

Before I changed xhr.withCredentials=true

1. I could see Set-Cookie name & value in the response, but Chrome's "Application" tab in the Developer Tools showed me the name and an empty value
2. Subsequent requests did not send a Cookie request header.

After the change xhr.withCredentials=true

1. I could see the cookie's name and the cookie's value in the Chrome's "Application" tab (a value consistent with the Set-Cookie header).
2. Subsequent requests did send a Cookie request header with the same value, so my server treated me as "authenticated"

---

Setting Access-Control... headers in server response

As for the response, if your request is a cross-site request, the server will need certain Access-Control... headers

For example, I configured my server to return these headers:

• Access-Control-Allow-Credentials:true
• Access-Control-Allow-Origin:https://{your-origin}:{your-port}

Until I made this server-side change to the response headers, Chrome logged errors in the console like

Failed to load https://{saml-domain}/saml-authn: Redirect from https://{saml-domain}/saml-redirect has been blocked by CORS policy:

The value of the 'Access-Control-Allow-Credentials' header in the response is '' which must be 'true' when the request's credentials mode is 'include'. Origin https://{your-domain} is therefore not allowed access.

The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

After making this Access-* header change, Chrome did not log errors; the browser let me check the authenticated responses for all subsequent requests.

Can't use wildcard/asterisk Access-Control-Allow-Origin:*, use dynamic value based on request

Using withCredentials and setting Access-Control-Allow-Origin:* (aka wildcard, allowing "all origins") won't work. As seen in the comments and described here (thanks to @ChandanBhattad). You might see this error:

The CORS request was attempted with the credentials flag set, but the server is configured using the wildcard ("*") as the value of Access-Control-Allow-Origin, which doesn't allow the use of credentials.

Therefore if you control the server and you want to allow cross-origin requests from any origin, you must dynamically decide the response value based on the request origin, or as MDN says:

If the server supports clients from multiple origins, it must return the origin for the specific client making the request.

For example, your server should inspect the request, if the request comes from http://www.example.com, your response headers should include:

Access-Control-Allow-Origin: http://www.example.com
Vary: Origin

Note the use of the Vary response header, which MDN says:

indicates to browsers that server responses can differ based on the value of the Origin request header.

How to change your server response headers depends on your server technology.

• Some example .NET WebAPI / .NET Core resources here, here, and here
• Some Node.js express examples here
• Some Python django examples here and mentioned here
• etc...

Answer 3

If you're using the new fetch API, you can try including credentials:

fetch('/users', {
  credentials: 'same-origin'
})

That's what fixed it for me.

In particular, using the polyfill: https://github.com/github/fetch#sending-cookies

Answer 4

This may help somebody randomly falling across this question.

I found forcing a URL with https:// rather than http:// even though the server hasn't got a certificate and Chrome complains will fix this issue.

Answer 5

In my case, the cookie size exceeded 4096 bytes (Google Chrome). I had a dynamic cookie payload that would increase in size.

Browsers will ignore the set-cookie response header if the cookie exceeds the browsers limit, and it will not set the cookie.

See here for cookie size limits per browser.

I know this isn't the solution, but this was my issue, and I hope it helps someone :)