While these mechanisms seem to be well-documented and have simple APIs, handling 3rd-party cookies is a little bit vague. In particular, I was interested in What exactly does it mean when user disables 3rd-party cookies?.
It turned out not so complicated, but you don’t know this until you actually have to use it, so hopefully this will help someone in future.
I’ve done a quick testing trying to answer those questions and here is what I found. Everything was checked on Firefox 41.0.2, Google Chrome 46.0.2490.71, and Safari 9.0 under Mac OS El Capitan.
- First of all, when 3rd-party cookies are disabled, browsers do not save, nor send
cookies for domains other than the top-level window (current page). This affects all cross-domain requests including resources (e.g.
<img>tags), iframes, and XMLHttpRequests (including CORS). This is something that you would expect, actually.
- If there is a cookie that was set previously as a 1st-party, it won’t be used.
will be thrown, but
document.cookiewill always return an empty string, even if you set it to something.
- No cookies in CORS requests too, even if you use
.withCredentialsparameter. Cookie header from server is just ignored.
- 3rd-level subdomains and sibling 3rd-level subdomains are not considered 3rd-party: foo.example.com can load an iframe pointing to bar.example.com and it will be allowed to set cookies.
sessionStorage is a bit more tricky:
- in Google Chrome any attempt to access
localStoragewill result in
- in Safari,
localStorageitself don’t raise errors, but if you try to use
localStorage.setItem(), it will give you a
- in Firefox, localStorage and sessionStorage are still working inside iframes. So you can save stuff in localStorage, and it will stay there. However, this will change in upcoming Firefox 43.
The term “3rd-party cookie” (actually “3rd-party origin”), seems to have different meanings across browsers. For example, Safari by default does send cookies to third-party domains, if it was visited before. There is a very nice story about that by Alex Volkov. Worth reading.
If you need to detect if 3rd-party cookies are enabled, one option is to take
advantage of always-empty
document.cookie. Just create an iframe pointing to
a page on another domain like this:
If you really need to access cookies on another domain, there are some ways to do so.
The most bullet-proof one is just make sure that cookies are 1st-party. Essentially, it means redirects. So you can redirect user to a page on another domain, set the cookie there, and then immediately redirect him back. This is not the best user experience, but it works.
In some cases it is possible to use a subdomain for setting cookies. If you have
example.com DNS, you can create a CNAME record
pointing to a server that needs to set cookies. Provided that cookies are not
host-only (that is, they are set with domain attribute specified), you can
share cookies between those domains.
What I have described above, is just a top of the iceberg. It is sufficient to understand the immediate side-effects of blocked cookies, but if you are really going to address this issue, you will most likely come across many caveats. And I believe there is no ideal solution to this problem.
On the other hand, the 3rd-party cookies problem has been there for a while, and now you can find lots of nice articles and posts with all kinds of reusable ideas. Check out this post by Alex Volkov for example.