db 级 ACL 过滤

Question

我正在为此查看 Spring-security 3.0，spring 的 ACL 过滤发生在 post(api call) 操作中。有两个问题：-

1. 它会破坏分页查询
2. 即使我在 api 获取结果上方的层上进行分页（我在这里使用 spring-hibernate），每次 db 查询都是浪费的，因为它会获取并填充所有结果，即使它们中的大多数注定要被过滤在 Java 级别输出

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

Answer 1

对于您提到的问题，只有#1 对我来说才是真正的问题。

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

我已经看到了每个查询都附加了 acl 的解决方案 在数据库级别进行过滤的查询，但看起来很难看 因为它污染了与授权有关的业务逻辑，是否存在 任何方式/框架可以透明地进行 db 级 acl 过滤？一世 像 spring-security 执行安全性的整体方法 通过 config/annotations 以声明方式，从而节省代码 直接与安全相关的逻辑，

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

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

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

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

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