对 WCF 服务的跨站点 ajax 调用
是否可以使用 Javascript 对 WCF 服务进行跨站点调用？
我不介意它是 POST 还是 GET。
但我听说现在浏览器不允许使用 POST 或 GET 进行跨站点调用。
我怎样才能绕过这个问题并仍然调用WCF服务？
Is it possible to do a cross-site call, in Javascript, to a WCF service?
I don't mind if it's a POST or a GET.
But I've heard that these days, browsers don't allow cross-site calls with either POST or GET.
How can I circumvent this and still call a WCF Service?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您无法采取很多措施来规避浏览器的跨站点脚本拦截器。 这些拦截器会阻止 XMLHTTPRequest 发生在除加载包含脚本或页面的域之外的任何域中。
也就是说，有一种常用的解决方法：使用 JavaScript 在 DOM 中写入一个新条目，该条目引用作为跨站点 URL 的 src。 您将把所有 RPC 方法参数传递给这个“脚本”，它将返回一些将要执行的 JavaScript，告诉您成功或失败。
无法以这种方式执行 POST，src URL 必须是 GET，因此您可以通过这种方式传递参数。 我不确定 WCF 是否有“仅 GET”访问方法。 而且，由于浏览器期望远程标记的结果是有效的 JavaScript 对象，因此您必须确保您的 WCF 服务也遵守这一点，否则您将收到 JavaScript 错误。
规避跨站点脚本的另一种常见方法是为您的请求编写代理。 换句话说，如果您想从 example.com 上托管的脚本访问域 test.com，请在 example.com 上创建一些 URL，以正确的方式将请求代理到 test.com。
对于您的示例，假设 WCF 没有自己的跨站点脚本限制，代理可能是正确的答案。
There's not a whole lot you can do to circumvent the browser's cross-site scripting blockers. Those blockers stop XMLHTTPRequest's from happening to any domain but the one that loaded the containing script or page.
That said, there is one commonly used workaround: Use JavaScript to write a new entry into the DOM that references a src that is a cross-site URL. You'll pass all your RPC method arguments to this "script" which will return some JavaScript that will be executed, telling you success or failure.
There's no way to do a POST in this manner, the src URL must be a GET, so you can pass arguments that way. I'm not sure if WCF has a "GET only" method of access. And, since the browser will expect the result of the remote tag to be a valid JavaScript object, you'll have to make sure that your WCF service obeys that as well, otherwise you'll get JavaScript errors.
Another common method of circumventing cross-site scripting is to write a proxy for your requests. In other words, if you want to access domain test.com from scripts hosted on example.com, then make some URL on example.com that proxies the request over to test.com in the proper way.
For your example, the proxying is likely the right answer, assuming that WCF doesn't have it's own cross-site scripting restrictions.
你有使用过 jQuery 吗？ jQuery 使用“JSONP”支持跨域 JSON 请求。 您将被限制为 GET 请求，但我已经尝试过了，效果很好！ 开始工作也非常简单。
有关详细信息，请参阅本页上的“跨域 getJSON（使用 JSONP）”部分：
http://docs.jquery.com/Release:jQuery_1.2/Ajax
以下是 JSONP 的一些背景知识：
http://bob.pythonmac.org/archives/2005 /12/05/remote-json-jsonp/
让我知道进展如何！
Are you using jQuery by any chance? jQuery supports Cross-Domain JSON requests using "JSONP". You will be limited to GET requests, but I've tried it out and it works well! It's also very simple to get working.
See the "Cross-Domain getJSON (using JSONP) " section on this page for details:
http://docs.jquery.com/Release:jQuery_1.2/Ajax
And here's some background on JSONP:
http://bob.pythonmac.org/archives/2005/12/05/remote-json-jsonp/
Let me know how it goes!
新的 W3C 建议正在标准化，以允许受信任方之间通过跨站点访问控制进行跨站点请求-站点请求规范。
这需要一个提供合适的访问控制 HTTP 标头的服务器和一个能够理解此类标头并对其进行操作的浏览器。
简而言之，如果远程主机表示它喜欢您的域，并且浏览器理解这意味着什么，那么无论同源策略如何，您都可以针对该主机执行 xmlHttpRequest。
目前很少有浏览器支持此功能。 IE8 显然可以（我还没有测试过），而 Firefox 3.1 可以（我已经对此进行了广泛的测试）。 我预计其他浏览器也会很快效仿。
最早要到 2012 年，您才能期望兼容浏览器得到充分采用。
这才是问题的最终解决办法。 缺点是要等待几年才能在主流应用中使用。
如果这是在您完全控制的环境中使用，例如在 Intranet 中，您可以确定使用哪个浏览器以及可以配置多个服务器来发出正确的标头，那么它可以完美地工作。
New W3C recommendations are being standardised to allow cross-site requests between trusted parties via the Access Control for Cross-Site Requests specification.
This requires a server serving suitable Access Control HTTP headers and a browser capable of understanding and acting upon such headers.
In short, if a remote host says it likes your domain, and a browser understands what this means, you can perform xmlHttpRequests against that host regardless of the same origin policy.
Currently very few browsers support this functionality. IE8 apparently does (I haven't tested it) and Firefox 3.1 does (I have tested this extensively). I expect other browsers to follow suit quite quickly.
You shouldn't expect sufficient adoption of compatible browsers until 2012 at the earliest.
That's the ultimate solution to the problem. The downside is waiting a few years before it can be used in mainstream applications.
If this is for use within an environment you fully control, such as for an intranet where you can determine which browser is used and where you can configure multiple servers to issue the correct headers, it works perfectly.
为了扩展 Ben 的答案...我使用类似于 Microsoft 的此示例的代码扩展了我们的 WCF 服务以支持来自 jQuery 的 JSONP 调用：
http://msdn.microsoft.com/en-us/library/cc716898.aspx
To expand on Ben's answer... I extended our WCF service to support JSONP calls from jQuery using code similar to this example from Microsoft:
http://msdn.microsoft.com/en-us/library/cc716898.aspx