How To Have Controller Share A Cookie With Service

7 Keys to the Mystery of a Missing Cookie

Photo past Emiliano Vittoriosi on Unsplash

One twenty-four hour period my colleague reported he couldn't admission a certain website. On every endeavor he had been redirected dorsum to the login page. I browsed to that website and surprisingly everything was working fine for me.

Nosotros checked our browsers and found out that nosotros both are using the same version of the Chrome. What went wrong was that in his case session cookie was not passed along the request to the backend service and the backend replied with http status lawmaking 401 — Unauthorized.

There are a couple of reasons why the browser would not attach a cookie to the request even if we are expecting it to do so. This incident and it's troubleshooting inspired me to sum them up hither. What caused my colleague's issue is marked as 1. in this blog. Earlier we proceed to information technology let's start by hitting F12 and opening the developer console to run into what cookies and their properties we have set up.

Path: if / the cookies will be sent for all paths

HttpOnly: if truthful, the cookie cannot be accessed from inside the client-side javascript code.

Secure: cookie has to be sent over HTTPS

SameSite: Lax, Strict, None or non set. Instructs browser whether or non to sent cookie in instance of cantankerous-site requests

Domain: The domain for which the cookie is set and can be sent to.

Max-Age : Time to live of the cookie

one. SameSite attribute Defaults to Lax

SameSite is an aspect of a cookie which tells the browser whether to attach a cookie to the cross-site request.

There was a breaking modify recently with Chrome and other browsers will probably follow this behaviour shortly. The thing is that cookies which do not have the SameSite value explicitly prepare, were previously treated as SameSite=None.

Now, equally of the version 80 of Chrome (canary released to gradually increasing population — that's why we were with my colleague experiencing different behaviour fifty-fifty if having the same version installed), they are treated as Lax so they are not sent along when e.g. XHR asking is targeting the domain which is different then the origin.

If we are browsing the website http://world wide web.instance.com and the website triggers XHR request to http://myexam.ple/, cookies without SameSite which are stored in the browser for http://myexam.ple domain will not be sent forth the request.

As of July 2020 Chrome started release of yet another closely related feature. If the cookie's attribute SameSite is None the cookie has to be set up with flag Secure. If the cookie doesn't have the Secure flag, the browser ignores the Set-cookie server'due south response header and the cookie is non stored to the browser. If y'all got this wrong, you lot probably see in the the developer console following error bulletin:

A cookie associated with a cross-site resource at https://myexam.ple/ was fix without the `SameSite` attribute. A futurity release of Chrome volition only deliver cookies with cross-site requests if they are gear up with `SameSite=None` and `Secure`

More about SameSite attribute and cantankerous-site requests could be found in the dainty and explanatory blog post here.

Troubleshooting tip: In Chrome type in the URL chrome://flags and disable these 2 flags: SameSite by default cookies and Cookies without SameSite must exist secure. If this helped, yous now know the outcome and y'all can apply the fix.

Solution tip: Modify the server code to explicitly gear up the cookie's SameSite aspect to None.

This is a sample lawmaking of the controller written in Coffee Spring Boot of how to add together a server response header to prepare a cookie named "myCookie" of value "hullo" with the attribute SameSite=None and flag Secure.

Note: SameSite=None opens the door to the cross-site request forgery vulnerability. Information technology'south strongly suggested to consider having some other CSRF protection in place.

2. withCredentials is not Prepare to True

When the website http://example.com which nosotros are browsing triggers a POST XHR asking to http://myexam.ple/api, the browser identifies this every bit cross-site request and it will non adhere cookies and authorization headers to the request unless the default behaviour is overridden by setting the withCredentials property of XHR request to true.

Solution tip: Modify your client code, so the XHR request has an option withCredentials prepare to truthful. Here is an instance of how to set the withCredentials property in a customer app written in Angular.

There are a couple of things you accept to brand sure in order tomakewithCredentials :trueaccept upshot. They are listed in the next section.

3. Preflight Request Blocks Credentials

Allow's have a closer await to what happens if we are browsing https://example.com and the website makes a Postal service request to http://myexam.ple/api.

The browser detects the cross-site requests and before proceeding with the POST to myexam.ple/api the browser automatically fires the OPTIONS preflight asking.

Note, that preflight requests are non triggered by GET requests since GET requests by definition are not intended to modify user information. Preflight requests are triggered by Mail, PUT and DELETE requests.

OPTIONS response headers instructs a browser how to compose the actual POST request. For withCredentials:true to take the upshot (discussed in #2), OPTIONS response headers must not be Admission-CONTROL-ALLOW-ORIGIN:*, instead it has to explicitly listing origins due east.1000. ACCESS-CONTROL-Permit-ORIGIN:http://myexam.ple

If y'all got this wrong you probably meet in the programmer console this error message:

The value of the 'Access-Command-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'. The credentials mode of requests initiated by the XMLHttpRequest is controlled by the withCredentials attribute.

It makes sense, yous don't want an arbitrary webpage called your API with credentials, don't you?

Bank check out the OPTIONS response header Access-Command-Let-CREDENTIAL whether information technology is gear up to true. If the server doesn't allow credentials being sent forth, the browser will simply not attach cookies and authorization headers. So this could be another reason why the cookies are missing in the Mail service cross-site request.

Troubleshooting tip: open up the programmer console and check in the Network tab what are the response headers from OPTIONS.

Solution tip: On your server lawmaking, set the appropriate response headers. Hither is the example of how this could exist done in Java Leap Boot.

4. Path is not Matching

If the cookie was set for Path / information technology ways that it is sent along all the requests targeting the domain for which it was set, e.thou myexam.ple/customers. All the same if the cookie Path was fix to /api, the cookie will exist sent only when request to path starting myexam.ple/api is made.

Troubleshooting tip: open the developer console, navigate to Application>Cookies and edit the path attribute directly in in that location to see if this helps

Solution tip : Fix the lawmaking to set the cookies with matching Path.

v. Domain is non Matching

The key aspect of the browser security is that a cookie is merely sent over to the host for which it was ready.

When setting a cookie for myexam.ple with Domain aspect omitted, it means that all requests to myexam.ple will be with the cookie, however requests to the subdomain subdomain.myexam.ple will non have the cookie fastened.

If the Domain is specified due east.g. Domain=myexam.ple, it means that a cookie will exist sent with the request to myexam.ple every bit well with the request to subdomain.myexam.ple.

Troubleshooting tip: open the developer console, navigate to Application>Cookies and edit the Domain attribute directly in there to run into if this helps.

Solution tip: Alter the code where you are setting the cookie to fix the Domain aspect accordingly.

half-dozen. Cookie Name is Prefixed with '__Host'

Cookie prefixes is an boosted style to instruct a browser how the cookie should be treated.

Cookies prefixed with __Host are sent merely to the host which ready the cookie and never sent to subdomains. Then if the cookie __Host_mycookie is set for http://case.com and your request targets http://sub.example.com/api the cookie is not attached.

Cookie prefixes are well explained in this post.

Note, that __Host cookies cannot have Domain attribute prepare.

seven. Cookie is Expired (Expires/MaxAge is in By)

Last point, that a cookie could exist expired, is and then obvious that I fifty-fifty hesitated to mention information technology hither. Everything has to come to its end, including the cookie's life and this blog post equally well…

Give thanks you lot for reading and if you faced whatsoever other reason for cookie existence lost I would dearest to hear back from you.

Resources

https://world wide web.chromestatus.com/feature/5088147346030592 — Chrome's release notes on SameSite behaviour
https://web.dev/samesite-cookies-explained/ — SameSite attribute explained
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00 — Cookie prefixes and reasons for their introducing explained
https://programmer.mozilla.org/en-US/docs/Spider web/HTTP/Cookies — All nearly cookies under one hood