IE8 - IE10 cross domain JSONP cookie headache

Question 1

In short

Cookies will NOT go through a cross-origin request on IE 8 and 9. It should work on IE 10 and 11 though.

IE 8 and 9

On IE8/9 XMLHttpRequest partially supports CORS, and cross-origin requests are made with the help of the XDomainRequest object which does NOT send cookies with each request.

You can read more about this on the following official MSDN Blog post:
http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

Particularly this part:

5 . No authentication or cookies will be sent with the request

In order to prevent misuse of the user’s ambient authority (e.g. cookies, HTTP credentials, client certificates, etc), the request will be stripped of cookies and credentials and will ignore any authentication challenges or Set-Cookie directives in the HTTP response. XDomainRequests will not be sent on previously-authenticated connections, because some Windows authentication protocols (e.g. NTLM/Kerberos) are per-connection-based rather than per-request-based.

IE 10+

Starting with IE10, full CORS support was added to XMLHTTPRequest and it should work fine with a correct Access-Control-Allow-Origin header property on the response from the server (that wishes to set the cookie on the browser).

More about this here:
http://blogs.msdn.com/b/ie/archive/2012/02/09/cors-for-xhr-in-ie10.aspx
And here:
http://www.html5rocks.com/en/tutorials/cors/

Workarounds on IE 8 and 9

The only way to go around this on IE8/9 is, quoting the same MSDN post as above:

Sites that wish to perform authentication of the user for cross-origin requests can use explicit methods (e.g. tokens in the POST body or URL) to pass this authentication information without risking the user’s ambient authority.

Question 2

Bottom line: third party cookies are commonly blocked by privacy/advertisement blocking extensions and should be considered unreliable. You'll be shooting yourself in the foot leaving it in production.

The syntax suggests that the endpoint has ambitions to one day become RESTful. The only problem with that is using cookies, which throws the whole "stateless" concept out of the window! Ideally, changes should be made to the API. If you are not integrating with a third party (i.e. "secure.com" is operated by your company) this is absolutely the correct way to deal with the issue.

Move the cartId out of the secure.com cookie into its querystring:

secure.com/product/add/9876?cartId=1234    //should be a POST

Where to get a valid cartId value? We can persist it in some secure-com-cart-id cookie set for catalog domain, which will avoid any cross-domain issues. Check that value and, if present, append to every secure.com request as above:

$.post('secure.com/product/add/9876', {    //needs jQuery.cookie
  cartId: $.cookie('secure-com-cart-id')
});

If you don't have a valid cartId, treat it as a new user and make the request without the parameter. Your API should then assign a new id and return it in the response. The "local" secure-com-cart-id cookie can then be updated. Rinse and repeat.

Voila, you've just persisted an active user cart without polluting API calls with cookies. Go yell at your architect. If you can't do that (changing API syntax or yelling), you'll have to set up a tunnel to secure.com endpoint so that there will be no cross-domain request - basically something sitting at catalog.org/secure-com-endpoint which will channel the requests to secure.com verbatim. It's a workaround specifically to avoid making changes to the API, just don't do it with code and have proper Apache/IIS/F5 rules set up to handle it instead. A quick search comes up with several explanations, this one looks pretty good to me.

P.S.: this is a classic XY problem in my opinion. The solution isn't necessarily about persisting 3rd party cookies but about passing necessary parameters to a 3rd party while persisting the data somewhere.

Question 3

Although a correct solution would be a change of architecture, if you're looking for a quick, temporary solution:

JSONP files are actually just javascript. You could add a line of code to set cookies to the front of your JSONP.

eg instead of:

callback({"exampleKey": "exampleValue"});

Your JSONP could look like:

document.cookie="cartID=1234";
callback({"exampleKey": "exampleValue"});

Question 4

If you control the DNS records, create a new entry so both servers are in the same domain.

Question 5

Is there 1 database serving catalog.org and secure.com or can they communicate?

If so then, you got it.

When catalog.org servers a cookie, save it in the db. When secure.com servers a cookie, save it in the db. Then you can determine who's cart belongs to which user.

This is a fun problem to consider......Update 2:

When a user goes to catalog.org:

check if he has a cat_org cookie, if not, then:
- in catalog.org:
  - create a key value pair and save in the db {cat_cookie_id, unique_number}
  - set cat_cookie_id in browser
  - instruct the browser to ajax visit secure.com/register/unique_number
- in secure.com
  - read unique_number from url
  - create a secure_cookie id
  - save in the db {cat_cookie_id, unique_number, secure_cookie_id}
  - delete unique_number, as this is a one-time use key

Now the db can map cat_cookie_id to secure_cookie_id and vice versa.