我正在编写一个支持app.ourdomain.com/store的骨干应用程序。
我想使用内置于我们API的HTTP身份验证来访问api.ourdomain.com/ourApi上的数据。
现在,据我所知,响应中需要一个CORS头Access-Control-Allow-Origin: *
来允许这种跨源支持。
但是,这在IE8 / 9中不起作用。我读过SO&在其他地方,我可以简单地添加$.support.cors = true;
,这将神奇地开始使用IE8 / 9。
在我深入研究这个项目之前,我希望有实际经验的人能够回答这个问题:
如果我们编写API以处理飞行前OPTIONS请求,允许跨源请求,将此覆盖添加到$.support
对象,我们是否可以完全访问所有HTTP谓词(包括PUT) / DELETE),能够在IE8 / 9中进行身份验证并包含自定义标头(就像我们在使用XMLHttpRequest的所有现代浏览器中一样)?
This article描述了IE8 / 9用于此类请求的XDomainRequest
对象的限制/限制。我特别关注#3& #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的请求应该正常工作,而无需修改任何其余代码。