Asked By: Anonymous
I’m writing a backbone app that’s going to live on app.ourdomain.com/store.
I’d like to access data on api.ourdomain.com/ourApi, using HTTP Authentication already built in to our API.
Now, as I understand it, a CORS header,
Access-Control-Allow-Origin: *, is required in the response to allow this cross-origin support.
However, this does not work in IE8/9. I’ve read on SO & elsewhere that I can simply add
$.support.cors = true; and this will magically start working on IE8/9.
Before I get too deep into this project, I’m hoping somebody with practical experience can answer this:
If we code up our API to handle the pre-flight OPTIONS request, allowing the cross-origin request, add this overrride to the
$.support object, will we then get full access to all HTTP verbs (including PUT/DELETE), the ability to authenticate, and include custom headers in IE8/9 (like we do in all modern browsers using the XMLHttpRequest)?
This article describes the restrictions/limitations of the
XDomainRequest object that IE8/9 uses for these kinds of requests. I’m concerned specifically with #3 & #5 which state:
#3: No custom headers may be added to the request
We use a custom header to indicate the CustomerID that’s making the request
#5: No authentication or cookies will be sent with the request
We use HTTP Authentication to authenticate the user on the initial request, and on subsequent requests use an access_token returned during the original request.
Since IE8/9 support is mandated right now, does that mean I can’t use Backbone to request data to a different subdomain on our system, without doing something silly like create a proxy API on subdomainA to access data on subdomainB?
Answered By: Anonymous
Your assessment sounds correct. Unfortunately there is no workaround for custom headers, additional methods or cookies when using CORS in IE8/9 (IE10 should have full support for these).
A proxy server is one option. Another option is to host an html page on the remote domain, include this HTML page in an iframe on the calling page, and then use
window.postMessage to talk between the iframe and the calling page. Since the iframed page is on the same domain as the API, it can make a same-origin request using XHR, and then pass the data to the calling page using
postMessage (although they don’t seem to affect iframes). You can find a description of this “iframe proxy” mechanism here: