如何以安全的方式读取和写入 OData 调用？ （例如，不容易受到 CSRF 的影响吗？）
打开 OData 读取/GET 端点，没有 CSRF 攻击的风险，例如
我还没有查看源代码，但是 MSFT 是如何做到的ODATA 库 在这方面与 jQuery 进行比较：
What is the most secure way to open a OData read/GET endpoint without risks to CSRF attacks like this one?
I haven't looked at the source, but how does the MSFT ODATA library compare to jQuery in this regard:
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
OData 旨在通过仅返回对象作为 JSON 结果来防止链接中描述的 JSON 劫持攻击，这使得有效负载成为无效的 JavaScript 程序，因此浏览器不会执行。
这实际上与您使用 datajs 还是 jQuery 无关。我还没有查看从 jQuery 获得的确切结果，但我知道 datajs 会“展开”结果，以便您获得看起来更自然的结果，而不需要任何人为的顶级对象。
特别是，.NET 的 WCF 数据服务实现并不支持开箱即用的 JSONP，尽管有一些流行的简单解决方案可以添加它。不过，此时您基本上已经选择允许从其他域查看数据，因此对于用户敏感数据不应该这样做。
OData was designed to prevent the JSON-hijacking attack described in the link by returning only objects as JSON results, which makes the payload an invalid JavaScript program and as such won't be executed by the browser.
This is really independent of whether you use datajs or jQuery. I haven't looked at the exact result you get from jQuery, but I know datajs will "unwrap" the results so you get a more natural-looking result, without any artificial top-level objects.
In particular, the WCF Data Services implementation for .NET doesn't support JSONP out of the box, although there are a couple of popular simple solutions to add it. At that point, though, you've basically opted into allowing the data to be seen from other domains, so this is something that shouldn't be done for user-sensitive data.