2

我刚刚阅读了有关 OData 查询的 ASP.Net Web API 支持的内容，但在协调查询过滤的外部暴露时遇到了麻烦，这实质上为集成商提供了在数据库中抛出任意查询过滤器的能力，而无需考虑最佳查询计划、不应查询的字段等等。

如何清理 OData 查询，以便用户不能直接在数据库中抛出可怕的复杂查询，这可能会导致性能问题，并且可能包含对不应执行的字段的引用？

4

3 回答 3

2

我们正在考虑解决这些问题。从 Web API RC 开始，我们要求您明确注释您的方法，[Queryable]以表明您希望选择自动过滤行为。我们还在研究稍后将提供的其他一些可扩展性/自定义 API。

从根本上说，由于这是一个自动系统，因此需要开发人员有一定的了解才能了解所有性能/安全注意事项。从某种意义上说，它与参数模型绑定中的过度发布问题没有什么不同（例如，有人发布了一个将 IsAdmin 属性设置为 true 的 User 对象，即使您的 API 从未记录过它支持这样的属性。它恰好可以工作，因为模型您在服务器上使用的类型也具有 IsAdmin 属性）。这些问题可以通过编写特定的 DTO 对象来解决，这些对象严格控制您公开和接受哪些数据作为输入。

于 2012-06-02T18:59:24.370 回答
1

Web API 具有特殊的处理程序机制。因此，您可以检查和处理来自用户的查询。

http://www.asp.net/web-api/overview/working-with-http/http-message-handlers

但是对于 OData 查询，从数据库中公开 IQueryable 并不常见。常见的方法是在服务器上进行一般查询，“预先查询”，然后让用户能够查询或过滤这个预先查询的结果。而且您将确定用户无法使查询比预查询结果“更宽”。

请注意：WebAPI 仅支持 filter、top、skip、orderby。所以非常有限。对于正常的 OData 支持 - 使用 WCF 数据服务

当您想隐藏用户过滤/查询某些列时，一种方法是编写自定义处理程序，该处理程序将从用户解析 URI 并返回例如 403 错误，或者作为一种变体来制作没有这些列的 DTO 对象并将它们公开用于“预查询”给用户。

于 2012-06-02T10:17:06.123 回答
1

在我看来，这是使用 OData 查询语法的架构权衡。如果您不希望人们拥有不受限制的查询访问权限，请不要使用它。SQL 视图与 SQL 存储过程的论点是相同的。

于 2012-06-02T12:21:26.537 回答