数据库级ACL过滤

Question

我正在考虑Spring-security 3.0,Spring的ACL过滤发生在post(api call)操作中.有两个问题: -

1. 它会破坏分页查询
2. 即使我在api获取结果上面进行分页(我在这里使用spring-hibernate),每次db查询都是浪费,因为它获取并填充所有结果,即使它们中的大多数注定要在java中过滤掉水平

我已经看到了解决方案,其中每个查询都附加了在数据库级别进行过滤的acl查询,但是由于它在授权问题上污染了业务逻辑,这看起来很丑陋,是否有任何方法/框架可以透明地进行数据库级别的acl过滤？我喜欢spring-securities通过配置/注释以声明方式强制执行安全性的整体方法,从而直接从安全相关逻辑中删除代码,但我认为它在性能问题上失去了这一点

Answer 1

对于你提到的问题，只有第一个问题对我来说才是真正的问题。

对于第二个问题，如果我理解正确的话，它是返回结果列表的查询，没有任何分页行为。因此，应该假设结果的大小是有限的，并且不会增长到返回结果变得非常慢的程度。否则，您需要使该查询可分页并返回到第一个问题。考虑到有限的结果列表，我怀疑使用在应用程序级别的过滤@PostFilter会比在数据库级别的过滤变得明显慢。

我见过的解决方案中，每个查询都附加了 acl 查询，这些查询在数据库级别进行过滤，但这看起来很难看，因为它会污染业务逻辑并涉及授权问题，是否有任何方法/框架可以透明地进行数据库级别 acl 过滤？我喜欢 spring-security 通过配置/注释以声明方式强制执行安全性的整体方法，从而使代码直接免受安全相关逻辑的影响，

因此，对于第一个问题，如果您使用 Hibernate，您可以查看@Filter它允许您以声明方式定义一个 where 子句，该子句将在查询特定实体时附加到 select SQL 中。过滤器默认是关闭的，需要在每个事务中启用。where 子句也可以参数化。

这意味着你可以简单地使用 Spring AOP 定义一个注解来注解你想要启用授权的查询方法。然后在这个注解支持的建议中，打开这个过滤器并根据以下内容配置 where 子句的参数：当前用户信息（如有必要）。对于没有使用此注解进行注解的查询方法，过滤器被关闭并且不知道授权问题。

基本上它与将授权逻辑附加到查询中相同，但是借助 AOP 和 的性质@Filter，业务逻辑不知道任何授权逻辑。

如果 Hibernate 过滤器不适合您的要求，您可以研究哪些数据访问技术允许您通过向查询添加授权逻辑来轻松修改查询。例如，使用 JPA Criteria API 也是可能的，因为它提供了表示查询的对象模型，因此向查询添加授权逻辑就相当于调整查询对象。

这个想法是，您需要对数据访问层进行适当的设计，以便您可以使用 AOP 来配置底层技术，以轻松且一致的方式应用授权问题。并使用AOP将授权逻辑与业务逻辑分离。