jpillora / xdomain

A pure JavaScript CORS alternative
https://jpillora.com/xdomain/
3.12k stars 270 forks source link

Slave Cookie Header not working anymore when third party cookies blocked? #177

Closed tombebombe closed 8 years ago

tombebombe commented 8 years ago

Hello,

we recently discovered that the slave cookies were not being transferred to the web service anymore when third party cookies are disabled in the browser (FF 43.0.1 and Chrome 47.0.2526.106). We are fairly positive that this did work in the past, but are not 100% certain. (We're using xdomain v0.7.3) Looking at this page for help, we stumbled upon the master/slave cookie header feature. However, this also seems to not be working (anymore?). In Chrome, the slave header is simply empty, in FF, it isn't even there. As soon as you allow third party cookies, the headers are correctly set.

Our assumption here is that browser just don't allow reading the cookies in the iFrame anymore.

Can you replicate that problem? Maybe it is a web server related issue, but i doubt that. I don't have a fiddle at the moment, but if necessary, I can build one.

If this is the case, do you see any way to still get to the slave cookies?

Thanks in advance, Felix

jpillora commented 8 years ago

I haven't personally used XDomain cookies in quite some time so it's hard for me to test. Disabling 3rd party cookies should only remove the Cookie header, other headers should be set. Could you make cross-domain demonstration of this issue?

tombebombe commented 8 years ago

hello! i created a little test suite: http://uharc.net/~tombe/work/xdomain_test_cookie_header.html

on both domains (uharc.net and unfallkind.de), cookies are created and then a file is requested via ajax from unfallkind.de

it behaves just like in my initial report:

if you need anything further, please let me know!

regards, and thank you for your support, felix

jpillora commented 8 years ago

Hi Felix, I just did a bit of debugging. Unfortunately it looks like Slave-Cookie no longer works anymore. I was also quite sure it worked when I originally did my testing, I thought it was only preventing the Cookie header from being sent. Now, it also seems to prevent iframes from accessing to the document.cookie property. I also just looked into localStorage as an alternative though it also seems to prevent different-domain iframe access. I think the only solution is to use the cookies from the master domain...

tombebombe commented 8 years ago

Hello, thanks for the confirmation. That's exactly what we thought. I guess we have to find a way around that. Personally, I think that's how the block third party cookie option should work. Seems like Mozilla and Google now think so, too.

I wonder how Facebook and Google work around that...

Regards, Felix

jpillora commented 8 years ago

No worries. Just tested facebook, they just use POST https://www.facebook.com/login.php and then set cookies on the root facebook.com domain. Note, you can share cookies between subdomains, see http://stackoverflow.com/questions/18492576/share-cookie-between-subdomain-and-domain

tombebombe commented 8 years ago

Unfortunately, we have completely different domains in some cases. Fortunately, this should change in the near future. Hopefully before all browsers block third party cookies by default (like Safari does). With their like buttons embedded into other websites, Google+ and Facebook (now) open new windows, where they are within their own domain.

Thanks again and a happy new year! Felix