CODEWITHSUNDEEP
cookiescorsxmlhttprequest
Kenn
Kenn

Reputation: 2479

Debugging CORS requests which fail to set cookies even with CORS headers and withCredentials=true

There are many questions on StackOverflow of users making a CORS request which doesn't properly set cookies. I'm having the same problem, but I'm wondering if Chrome or another browser provides a method to diagnose and understand why the cookies aren't set.

I'm finding all kinds of things that can cause this: missing CORS headers, missing withCredentails=true, situations across https secure boundaries, certain flags on the cookies... I want to understand what Chrome is doing instead of just guessing why it doesn't work.

Here's my specific problem, but really I'm after a process to understand not just the fix.

Domain Creating Request:

Note withCredentails = true.

var xmlhttp = new XMLHttpRequest();
xmlhttp.onreadystatechange = function() {
  if (xmlhttp.readyState === XMLHttpRequest.DONE) {
    callback(xmlhttp);
  }
};
xmlhttp.open('POST', url, true);
xmlhttp.withCredentials = true;
xmlhttp.setRequestHeader('Content-Type', 'application/json');
xmlhttp.send(payload);

Request:

Notice that Chrome doesn't show any Set-Cookie headers for the request. enter image description here

Curl of same request:

But if I right-click > copy > cUrl and execute here are the raw headers include Set-Cookie:

curl 'http://satellite:6988/medic/login' -H 'Referer: http://upstream:5988/medic/login?redirect=http%3A%2F%2Fupstream%3A5988%2Fmedic%2F_design%2Fmedic%2F_rewrite%2F%23%2Fmessages%2Fcontact%3A13863168-be61-418a-aea1-1b19b9a5af39' -H 'Origin: http://upstream:5988' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36' -H 'Content-Type: text/plain;charset=UTF-8' --data-binary '{"user":"worker","password":"dSNH1sv2jzdB"}' --compressed -v
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to satellite (127.0.0.1) port 6988 (#0)
> POST /medic/login HTTP/1.1
> Host: satellite:6988
> Accept: */*
> Accept-Encoding: deflate, gzip
> Referer: http://upstream:5988/medic/login?redirect=http%3A%2F%2Fupstream%3A5988%2Fmedic%2F_design%2Fmedic%2F_rewrite%2F%23%2Fmessages%2Fcontact%3A13863168-be61-418a-aea1-1b19b9a5af39
> Origin: http://upstream:5988
> User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36
> Content-Type: text/plain;charset=UTF-8
> Content-Length: 43
> 
* upload completely sent off: 43 out of 43 bytes
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: http://upstream:5988
< Vary: Origin, Accept-Encoding
< Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS, HEAD, DELETE
< Access-Control-Allow-Headers: accept, authorization, content-type, origin, referer, x-csrf-token
< Access-Control-Allow-Credentials: true
< Set-Cookie: AuthSession=d29ya2VyOjVDMDdEMjgwOj06hJxoYrYGtUxNa3ImYd1AZ7Vw; Path=/
< Set-Cookie: userCtx=%7B%22name%22%3A%22worker%22%2C%22roles%22%3A%5B%22chv%22%5D%7D; Max-Age=31536000; Path=/; Expires=Thu, 05 Dec 2019 13:28:32 GMT
< Set-Cookie: satelliteServer=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 16
< ETag: W/"10-oV4hJxRVSENxc/wX8+mA4/Pe4tA"
< Date: Wed, 05 Dec 2018 13:28:32 GMT
< Connection: keep-alive
< 
* Connection #0 to host satellite left intact
{"success":true}

Upvotes: 3

Views: 1397

Answers (1)

Kenn
Kenn

Reputation: 2479

The Chrome console is helpful for understanding problems with CORS headers. Since it writes clear descriptive headers when a request is fully blocked.

For my particular scenario, I used chrome://net-internals/#events which contains cookie related events to understand that the Set-Cookie headers are omiited from developer tools but were being served, received, and properly set.

My issue was that I was setting options.credentials=true when using fetch on requests after the cookies were set instead of the required options.credentials='include'.

Upvotes: 3

Related Questions