18

Since jQuery ajax ist not working for CORS/IE, I'm using XDomainRequest to retreive data from another Server. Work's fine, but I would like to send some header ('Authentification', 'content-type').

Is there a chance to add/change header in XDomainRequest?

Or does someone know a workaround?

hippietrail
  • 13,703
  • 15
  • 87
  • 133
Johannes Staehlin
  • 3,550
  • 7
  • 32
  • 50

2 Answers2

17

This is what we did for IE.

If you have control over the target domain, host a (static) html file there. Include the html using the iframe.

Now this iframe does actually have access to the local domain, so you can communicate between the parent and child frame to get what you need.

This worked much better than XDomainRequest for us.

window.postMessage is the best way to setup the communication:

But I'm pretty sure that only started working since IE8. If you require older browsers as well, you must use a different hack.

In our case, this was our 3-layer system:

  1. CORS, for browsers that support it
  2. An iframe & window.postMessage as a primary fallback
  3. A server-side proxy script as the secondary fallback

All of these options work well, are reliable and didn't feel too much like a hack. The secondary fallback was barely ever used.

Keep in mind that the 'Authentication' header specifically is special, and I would not be shocked that that's blocked under certain circumstances anyway. We added a custom header 'X-Authenticate' as it did pass through all the time.

Evert
  • 75,014
  • 17
  • 95
  • 156
  • I had a look on the iframe workaround the last days. But since you have to set 'document.domain', it seems to work only for communication between two subdomains of the same TLD. But what about two different TLD? (I might have to digg deeper into proxy-server stuff on the weekend...) – Johannes Staehlin Mar 15 '12 at 02:07
  • The iframe solution *should* work if the iframe is hosted on the same domain as the API. If a proxy script is a solution for you, that may well be *much* easier for your purposes. Note that it's (usually) not so much a proxy-server, as it is just a server-side proxy script. – Evert Mar 15 '12 at 10:43
  • ok, I made the iframe stuff work. I'm passing an object with all information (headers, post-body,...) to the frame window, which performs the requests and return the response. :) About the proxy script: If I host the script on the API-Server, I still would have to send the request with the headers in Ajax. So the script would be on the same server as the 'request'-page? (=^ client)? This way IE allows me to send headers, body,etc. and the proxy send the request to the api-server (curl)?!? – Johannes Staehlin Mar 18 '12 at 09:28
  • Yes, in case of the Proxy script, it must live on the same domain as the 'calling page'. – Evert Mar 18 '12 at 10:37
2

IE's XDomainRequest does not allow custom headers to be set. See item #3 here: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx The XDomainRequest object is locked down to the point where it is difficult to make authenticated requests.

monsur
  • 39,509
  • 15
  • 93
  • 91
  • 1
    But there must be a workaround!?! Or is the IE worse than I thought? – Johannes Staehlin Mar 11 '12 at 22:05
  • 1
    Without the ability to set custom headers or cookies, I'm not sure of a good way of making authenticated requests. You could pass the auth credentials as a query parameter (I believe the OAuth2 user-agent flow allows this), however this may not be as secure (and should be done over SSL). Sorry, maybe someone else has a better answer :-) – monsur Mar 11 '12 at 22:28
  • I thought you just needed them to log into the other domains site. (thus setting the appropriate session cookies and auth headers). Then your XDomainRequest would use the session they established? I may be wrong though. – Daniel Moses Mar 13 '12 at 17:33
  • 14
    @JohannesStaehlin Yes, IE is worse than you thought. Doesn't matter what you thought about it; it's worse than that. – Ryan P Mar 13 '12 at 17:56