我正在为此查看 Spring-security 3.0,spring 的 ACL 过滤发生在 post(api call) 操作中。有两个问题:-
我见过解决方案,其中每个查询都附加有在 db 级别进行过滤的 acl 查询,但这看起来很难看,因为它会污染具有授权问题的业务逻辑,是否有任何方法/框架可以透明地进行 db 级别的 acl 过滤?我喜欢 spring-securities 通过配置/注释以声明方式强制执行安全性的整体方法,从而直接从安全相关逻辑中节省代码,但我认为它在性能问题上失去了这一点
最佳答案
对于您提到的问题,只有 #1 才是真正的问题。
对于#2 问题,如果我理解正确的话,它是返回没有任何分页行为的结果列表的查询。因此,应该假设结果的大小是有限的,并且不会增长到返回结果会变得非常缓慢的程度。否则,您需要将此查询设为可分页并返回到 #1 问题。鉴于有限结果列表,我怀疑使用 @PostFilter
在应用程序级别进行过滤将明显慢于数据库级别的过滤。
I have seen solutions where each query is appended with the acl queries which does the filtering at the db level , but that looks ugly as it pollutes business logic with authorization concern, are there any ways/frameworks that does db-level acl filtering transparently ? I like spring-securities overall approach of enforcing security declaratively through config/annotations thus sparing the code from security related logic directly,
因此,对于 #1 问题,如果您使用的是 Hibernate,您可以查看
@Filter
它允许您以声明方式定义一个 where 子句,该子句将在查询某个实体时附加到 select SQL 中。默认情况下,过滤器是关闭的,需要为每个事务启用。 where 子句也可以参数化。这意味着您可以简单地使用 Spring AOP 定义一个注解来注解您要启用授权的查询方法。然后在此注解支持的通知中,打开此过滤器并根据如有必要,当前用户信息。对于未使用此批注进行批注的查询方法,过滤器已关闭且不知道授权问题。
基本上它与将授权逻辑附加到查询相同,但是借助 AOP 和
@Filter
的性质,业务逻辑不知道任何授权逻辑。如果 Hibernate 过滤器不适合您的要求,您可以查看哪些数据访问技术允许您通过向查询添加授权逻辑来轻松修改查询。例如,使用 JPA Criteria API 也是可能的,因为它提供了表示查询的对象模型,因此向查询添加授权逻辑就相当于调整查询对象。
这个想法是您需要对数据访问层进行适当的设计,以便您可以使用 AOP 配置底层技术,以轻松且一致的方式应用授权问题。并使用AOP将授权逻辑与业务逻辑分离。
关于spring-security - 数据库级 ACL 过滤,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/11339231/