跨域 XHR/AJAX：可能的解决方法？
我只是有一个想法进行跨域 AJAX 调用，因为到目前为止它们确实是一个 PITA 需要处理。 这是一个我没有在网络上任何地方公开过的解决方案，因此由于某种原因它可能（可能是）有缺陷/危险，我现在似乎看不到，所以我请你告诉我如果这合法与否：
今天，如果您拥有一个域名 www.foo.com，您就无法发出 XML Http 请求来表示 www.bar.com。但是，如果您向 foo.com 创建一个 XHR，那么它会通过 cURL 请求（或套接字或其他任何东西？）向 bar.com 请求该页面。
您通常会设置您的 xhr，无论是 GET 还是 POST，但您将其发送到 foo.com/remote-xhr.php 并添加一个包含最初预期 URL 的“url”参数，以及包含以下内容的“params”参数：嗯，参数。
remote-xhr.php 解析“params”，调用“url”，并“echo”响应。
这绝对是一种权衡，因为： 1. 您进行了 2 次调用，而不是使用其他解决方案（脚本标记 hack/JSONP）进行一次调用；2. 您失去了可能拥有的任何身份验证，因为客户端没有请求该页面，但服务器正在请求该页面。 （你可以用唯一的 ID、salt 等来解决这个问题）；但是您将获得一个完全正常的 XHR 调用，可以与任何远程域一起使用！
我缺少什么？
I just had an idea to make cross-domain AJAX calls, because so far they really are a PITA to deal with.
This is a solution I haven't seen exposed anywhere on the web, so it might be (probably is) flawed/dangerous for some reason, which I can't seem to see now, so I'm turning to you to tell me if this is legit or not :
Today if you own a domain, www.foo.com, you cannont make XML Http Requests to say www.bar.com. But what if you made an XHR to foo.com, that would then ask bar.com for the page, through a cURL request (or a socket or anything ?).
You normally set up your xhr, be it a GET or a POST, but you send it to foo.com/remote-xhr.php instead and add a "url" parameter containing the originally intended URL, and "params" parameter containing, well, the parameters.
remote-xhr.php parses "params", and calls "url", and "echo" the response.
It's definitely a tradeoff, because : 1. you make 2 calls instead of one with other solutions (script tag hack/JSONP) and 2. you lose any authentication you might have had because the client isn't requesting the page but the server is (you can workaround it with unique IDs, salt, anything though) ; but you then have a perfectly normal XHR call that could work with any distand domain !
What am I missing ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我想您已经考虑过其中一些，但以防万一
如果您没有使用服务器端 XHR 传递进行任何类型的身份验证，您可能需要限制可以调用的 URL并解析参数以发现任何异常的 XSS 机会。
延迟的增加可能会给您的网络服务器带来压力，因为它可能会使请求/响应线程等待 cURL 响应返回的时间更长（除非您正在使用某种额外的异步架构）。缓存 cURL 响应可能是更好的选择，但根据您可能遇到的 POST 参数的变化数量，这可能不是一个选择。
我确信还有其他的依赖于您的应用程序，但我会继续说我正在做类似的事情，但这只是因为我支付了外部 API 的费用，而我不想直接向我的 AJAX 应用程序公开该 API。 .. 所以我对调用进行了相当程度的抽象，并将它们限制为几乎单个外部 URL。
I imagine you've already thought of some of these, but just in case not
If you aren't doing any kind of authentication with your server-side XHR pass-through, you might want to limit what URLs can be called and parse the params for any extra-weird XSS opportunities this presents.
The latency increase might put a strain on your webserver since it could be holding the request/response threads longer waiting for a cURL response to comeback (unless you're doing somekind of extra async architecture). Caching the cURL response might be preferrable, but depending on how many variations of your POST'ed parameters you might encounter, that might not be an option.
I'm sure there are others depending on your application, but I will go ahead and say that I'm doing something like this but only because I pay for an external API that I don't want to expose directly to my AJAX application... so I've pretty heavily abstracted the calls, and limit them to pretty much a single external URL.
这没什么问题。我在 AJAX 请求中使用了这个技巧。
Nothing wrong with that. I use that trick in my AJAX requests.
这是可行的，但请记住，您允许客户端告诉您的服务器要下载哪些数据。根据您的实现，它可能相当无害，但如果不安全，它很容易让您痛不欲生（也许将其限制在非常特定的域？）。
例如，某人可能会向您的处理程序发送多个请求，这些请求会返回 Linux ISO 或非法内容。
This is workable but keep in mind that you're allowing your server to be told, by a client, what data to download. Depending on your implementation, it could be fairly harmless but it could easily bite you in the ass if it's not secured (perhaps limit it to very specific domains?).
For instance, someone could send multiple requests to your handler that returns, say, a Linux ISO or something illegal.