我正在编写一个支持app.ourdomain.com/store的骨干应用程序。
我想使用内置于我们API的HTTP身份验证来访问api.ourdomain.com/ourApi上的数据。
现在，据我所知，响应中需要一个CORS头Access-Control-Allow-Origin: *来允许这种跨源支持。
但是，这在IE8 / 9中不起作用。我读过SO＆amp;在其他地方，我可以简单地添加$.support.cors = true;，这将神奇地开始使用IE8 / 9。
在我深入研究这个项目之前，我希望有实际经验的人能够回答这个问题：
如果我们编写API以处理飞行前OPTIONS请求，允许跨源请求，将此覆盖添加到$.support对象，我们是否可以完全访问所有HTTP谓词（包括PUT） / DELETE），能够在IE8 / 9中进行身份验证并包含自定义标头（就像我们在使用XMLHttpRequest的所有现代浏览器中一样）？
This article描述了IE8 / 9用于此类请求的XDomainRequest对象的限制/限制。我特别关注＃3＆amp; ＃5表示：
#3: No custom headers may be added to the request
我们使用自定义标头来指示发出请求的CustomerID
#5: No authentication or cookies will be sent with the request
我们使用HTTP身份验证在初始请求中对用户进行身份验证，并在后续请求中使用在原始请求期间返回的access_token。
由于现在强制要求IE8 / 9支持，这是否意味着我不能使用Backbone向我们系统上的不同子域请求数据，而不做像在subdomainA上创建代理API以访问subdomainB上的数据那样愚蠢的事情？
干杯。
答案 0 :(得分：3)
您的评估听起来不错。遗憾的是，在IE8 / 9中使用CORS时，没有自定义标头，附加方法或cookie的解决方法（IE10应完全支持这些）。
代理服务器是一种选择。另一种选择是在远程域上托管html页面，在调用页面的iframe中包含此HTML页面，然后使用window.postMessage在iframe和调用页面之间进行通信。由于iframed页面与API在同一个域中，因此它可以使用XHR发出同源请求，然后使用window.postMessage将数据传递到调用页面。
这个“iframe代理”机制仍需要对subdomainB进行一些黑客攻击，特别是托管iframed页面。然而，它可能仍然比完整的代理服务器更好，因为它是纯粹的基于HTML / JavaScript的解决方案。请注意，IE8 / 9仍有some restrictions postMessage（尽管它们似乎不会影响iframe）。您可以在此处找到此“iframe代理”机制的说明：
答案 1 :(得分：3)
看起来这个问题已经得到了解答，但遇到了它，并认为我会为将来遇到此问题的人添加此内容。
总之，我遇到了这个确切的问题并编写了一个库，作为Backbone同步的直接替换，它使用XDomainRequest对象在IE7 / 8/9中启用CORS。
https://github.com/victorquinn/Backbone.CrossDomain
有了这个，您应该能够在Backbone.js之后立即包含它，执行您的跨域请求，并且来自IE的请求应该正常工作，而无需修改任何其余代码。