Feature: Cookies settings for masters and slaves

[synth]

Through much effort, I've got Xdomain configured properly and I can see in the console it making the request through the iframe socket. However, the request coming through does not have the same cookies to my domain as whats sent when make a normal request through a tab.

I'm using ie8 and I've configured IE to be as "insecure" as possible to see if I can rule out issues. I've been reading about p3p policies, could this perhaps be the culprit for ie not sending the correct cookies via the iframe? I've set the header to be:

p3p:CP="CAO PSA OUR"

as per this SO advice: http://stackoverflow.com/questions/3547449/iframes-google-analytics-cookies-p3p

Any ideas why this isn't working?

[synth]

I'd like to add that I now see "blocked" when I go to View -> Webpage Privacy Policy in IE8.

[jpillora]

https://github.com/jpillora/xdomain/blob/gh-pages/src/master.coffee#L75-L76

https://github.com/jpillora/xdomain/blob/gh-pages/src/slave.coffee#L66-L67

So basically, set withCredentials on an XHR object and cookies will be sent as XDomain-Cookie. Normally withCredentials (XHR2 non-IE) would set Cookie though since XDomain uses iframes and many web browsers have disable 3rd party cookies on, we cannot set the Cookie header, hence XDomain-Cookie. This should be explained in the docs...

Haven't looked into IE cookies, will review a PR though :)

[synth]

Yea, we're already setting withCredentials on the xhr. I see the XDomain-Cookie header being sent in Fiddler, but two things: 1) the cookie is only for the master domain, not the domain of the request being sent. 2) While I see the header going out in Fiddler, I can't seem to see it server side. I'm wondering if because its a non-standard header, the rails server is throwing it out.

[jpillora]

Hey @synth sorry for the delay. Interesting, the slave cookies should be sent in a normal Cookie header, I guess 3rd party cookie blocking also blocks same-domain cookies since they're in an iframe. One option would be set XDomain-Master-Cookie and XDomain-Slave-Cookie headers?

[bradgessler]

:+1: this has been a really big problem for a large scale CORS deployment we run on one of our JS websites. We were using both native CORS and another polyfill but ultimately gave up in favor of server-side proxy to deal with disabled 3rd party cookie tracking in Firefox, Mobile Safari, and other browsers.

[jpillora]

@bradgessler would Master-Cookie and Slave-Cookie headers help? Pro: They'll be exactly the same as Cookie (from both domains) however they won't be blocked. Con: You'll need to do some server side stuff to push them down the cookie processing pipeline.

[bradgessler]

@jpillora totally. We'd be thrilled if the fix was adding headers to our server. I'd imagine our team would roll this into some sort of rack middleware if we go down this route and open source it.

[jpillora]

@bradgessler Awesome. Yep with Ruby (rack) and Node (connect), it'd be quite easy to create middleware to grab either or merge both. Just not sure about other web frameworks. Nevertheless, seems like a handy feature. Since XDomain's special handling of withCredentials isn't documented, I'll mark this issue as an enhancement, add this feature and docs. As the API, I'm thinking:

//modifiable defaults
xdomain.cookie = {
  master: 'Master-Cookie',
  slave: 'Slave-Cookie'
};

Then:

xhr.withCredentials = true;
...
xhr.send();

Will send cookies of the master and the slave with the names provided, where setting one to null would prevent it being sent.

[jpillora]

This is implemented in 0.7.3 see https://github.com/jpillora/xdomain#xdomaincookies