跨子域ajax调用
我们希望构建一个 Web 应用程序，该应用程序将使用我们的 REST API 并寻找一种方法来规避同源策略安全功能。
我们有一个 REST API，由 SERVER_1 的 api.ourdomain.com 提供服务。 我们有一个Web应用程序，它是来自SERVER_2的dashboard.ourdomain.com的服务器。
Web 应用程序使用 Ajax 调用（包括 GET、POST、DELETE 和 PUT 请求）与 REST API 进行通信。
在未来的某个时候，我们可能会考虑允许第三方站点从他们自己的站点和域访问 API。
由于浏览器的同源策略安全功能，这些请求是不被允许的。
我们正在寻找规避此问题的方法。
我们遇到的解决方案：
- 通过我们的代理传输请求。这会减慢应用程序的速度并需要更多资源。
- JSONP - 仅适用于 GET 请求。我们不希望使用 post/put/delete 功能使 GET 请求过载。
- 使用 iFrame 并将 document.domain 设置为同一域。仅适用于 ourdomain.com 下的网站。
- EasyXDM 等框架。似乎是一个很好的解决方案。
谢谢你！
We wish to build a web app that will consume our REST API and looking for a way to circumvent the Same Origin Policy security feature.
We have a REST API which is served from api.ourdomain.com from SERVER_1.
We have a Web App which is server from dashboard.ourdomain.com from SERVER_2.
The Web App communicates with the REST API using ajax calls that include GET, POST, DELETE and PUT requests.
At some point in the future, we might consider allowing 3rd party sites to access the API from their own sites and domains.
Due to the Same Origin Policy security feature of the browsers, these requests are not allowed.
We are looking for ways to circumvent this.
Solutions we have encountered:
- Tunneling the requests through our proxy. This will slow down the app and requires more resources.
- JSONP - Will only work for GET requests. We do not wish to overload the GET requests with post/put/delete capabilities.
- Using an iFrame with document.domain set to the same domain. Will only work for sites under ourdomain.com.
- Frameworks such as EasyXDM. Seems like a good solution.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不了解 EasyXDM，但我在多个应用程序中拥有您所谈论的相同架构。我们使用您建议的解决方案 (1)。在我看来，通过公共子域代理请求是最干净的解决方案。我不认为这是一个性能问题。许多网站无论如何都会使用 nginx 之类的东西来执行某种反向代理（作为缓存）。您可以轻松地通过 http://[yourhost]/api 隧道传输您的 API，并通过其他路径传输其余的 HTML、CSS 和图像资源。
I don't know EasyXDM but I have the same architecture you are talking about in more than one application. We use your suggested solution (1). In my opinion proxying the requests through a common subdomain is the cleanest solution. I don't think that this is a performance problem. Many sites use something like nginx anyway to do some sort of reverse proxy (as cache). You could easily tunneling your API through http://[yourhost]/api and the rest of the HTML, CSS and image resources through other paths.