我们有许多安全功能可阻止访问基于用户角色和权限的各种OData v4（Microsoft OData v4实施）操作。在某种程度上，它是记录级访问权限。 这些安全检查在控制器操作本身中实现，即数据在基于SQL连接的EF LINQ查询过滤器中直接过滤到用户权限。 但是，只要{{ 1}}并不适用于任何地方（我们不想要）我们发现任何用户都可以[Queryable(MaxExpansionDepth = 0)]添加到任何URL并获得他喜欢的任何相关实体，而无需通过安全检查为每个标准实体路由定义的操作。例如，如果用户可以访问$expand，但由于在控制器操作实现的主体内应用了该路由的安全检查，/OData/Projects/无法访问与项目5关联的员工，则用户可以只需访问/OData/Projects(5)/Employees/。
除了通过/OData/Projects(5)?$expand=Employees($expand=SalaryInfo)完全阻止导航属性之外，似乎没有办法阻止我找到这个。
如果因为OData EDM已经知道它们与之关联的实体和Web API路由，那么理想的是，所有导航属性都可以设置为通过现有的OData Web API控制器操作来提供实体。换句话说，如果{0}处理MaxExpansionDepth以/OData/Projects(5)?expand=Employees($expand=SalaryInfo)处理/OData/Employees/然后使用这些控制器操作而/OData/Projects(5)处理/OData/Employees/Salary，那将是理想的选择而不是通过EF的SQL连接，只是因为EDM知道这些实体映射到那些路由的事实。这样我们就可以在一个地方定义我们的授权逻辑（控制器动作），同时仍然享受$ expand语法的灵活性。我希望有什么愚蠢的不合理吗？
我见过this solution但问题就变成了我们对安全性的单独定义，除非该解决方案中的安全性定义本身调用了该动作，即使那时它只是一个阻塞而不是一个条件数据过滤器正如我们已经实施的那样。
如果没有，我们将不得不在我们系统中每个易受攻击的API端点上解决[Queryable(MaxExpansionDepth = 0)]问题。