2

我正在编写一个将在 app.ourdomain.com/store 上运行的主干应用程序。

我想使用我们 API 中已经内置的 HTTP 身份验证访问 api.ourdomain.com/ourApi 上的数据。

现在，据我了解，Access-Control-Allow-Origin: *响应中需要一个 CORS 标头 ，以允许这种跨域支持。

但是，这在 IE8/9 中不起作用。我已经阅读了 SO 和其他地方，我可以简单地添加$.support.cors = true;，这将神奇地开始在 IE8/9 上工作。

在我深入这个项目之前，我希望有实践经验的人可以回答这个问题：

如果我们编写我们的 API 来处理飞行前的 OPTIONS 请求，允许跨域请求，将这个覆盖添加到$.support对象中，那么我们将获得对所有 HTTP 动词（包括 PUT/DELETE）的完全访问权限，以及身份验证的能力，并在 IE8/9 中包含自定义标头（就像我们在所有使用 XMLHttpRequest 的现代浏览器中所做的那样）？

本文XDomainRequest描述了IE8/9 用于此类请求的对象的限制/限制。我特别关心#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 上的数据？

干杯。

4

2 回答 2

3

你的评估听起来是正确的。不幸的是，在 IE8/9 中使用 CORS 时，没有针对自定义标头、附加方法或 cookie 的解决方法（IE10 应该完全支持这些）。

代理服务器是一种选择。另一种选择是在远程域上托管一个 html 页面，将此 HTML 页面包含在调用页面的 iframe 中，然后用于window.postMessage在 iframe 和调用页面之间进行对话。由于 iframed 页面与 API 在同一个域中，因此它可以使用 XHR 发出同源请求，然后使用window.postMessage.

这种“iframe 代理”机制仍然需要对 subdomainB 进行一些黑客攻击，特别是托管 iframe 页面。然而它可能仍然比一个成熟的代理服务器更好，因为它是一个纯 HTML/JavaScript 的解决方案。请注意，IE8/9 仍然有一些限制postMessage（尽管它们似乎不影响 iframe）。您可以在此处找到此“iframe 代理”机制的描述：

于 2013-01-18T20:47:33.530 回答
3

看起来这个问题已经回答了，但是遇到了它，我想我会为将来遇到这个问题的人添加这个。

总之，我遇到了这个确切的问题，并编写了一个库来替代 Backbone 的同步，它使用 XDomainRequest 对象在 IE7/8/9 中启用 CORS。

https://github.com/victorquinn/Backbone.CrossDomain

有了这个，你应该能够在 Backbone.js 之后包含它，进行跨域请求，来自 IE 的请求应该可以正常工作，而无需修改任何其余代码。

于 2013-05-16T16:59:24.523 回答