我正在考虑Spring-security 3.0，spring的ACL过滤发生在post（api call）操作中。有两个问题： -
我已经看到了解决方案，其中每个查询都附加了在数据库级别进行过滤的acl查询，但是这看起来很丑，因为它污染了具有授权问题的业务逻辑，是否有任何方法/框架可以执行db-level acl透明过滤？我喜欢Spring-securities通过配置/注释以声明方式强制执行安全性的整体方法，从而直接从安全相关逻辑中删除代码，但我认为它在性能问题上失去了这一点
答案 0 :(得分：0)
对于您提到的问题，只有＃1是我真正的问题。
对于第二个问题，如果我理解正确，则该查询将返回没有分页行为的结果列表。因此，应该假定结果的大小是有限的，并且不会增长到返回结果变得非常慢的程度。否则，您需要使此查询成为可分页的查询，并返回到第一问题。给定有限的结果列表，我怀疑使用@PostFilter在应用程序级别进行的过滤是否会比在数据库级别进行过滤的速度明显变慢。
我已经看到了将每个查询附加到acl的解决方案 查询在db级进行过滤的查询，但是看起来很丑 因为它会污染与授权相关的业务逻辑， 数据库级acl透明地进行过滤的任何方式/框架？一世 像春季安全性执行安全性的整体方法 通过配置/注释进行声明，从而节省了代码 与安全性直接相关的逻辑，
因此对于＃1问题，如果您使用的是Hibernate，则可以签出@Filter，它允许您声明性地定义在查询某些实体时将附加到select SQL的where子句。过滤器默认情况下处于关闭状态，并且需要在每个事务中启用。where子句也可以参数化。
这意味着您可以简单地使用Spring AOP定义一个注释来注释要启用授权的查询方法。然后在此注释支持的建议中，打开此过滤器并为where子句配置参数基于当前用户信息（如有必要）。对于未使用此注释注释的查询方法，过滤器将关闭并且不知道授权问题。
基本上，与将授权逻辑附加到查询中相同，但是借助AOP和@Filter的性质，业务逻辑不知道任何授权逻辑。
如果Hibernate过滤器不适合您的要求，则可以查看哪些数据访问技术可通过向其添加授权逻辑来轻松修改查询。例如，使用JPA Criteria API也是可能的，因为它提供了表示查询的对象模型，因此向查询中添加授权逻辑等同于调整查询对象。
这个想法是，您需要对数据访问层进行适当的设计，以便可以使用AOP来配置基础技术，以轻松，一致地应用授权问题。并使用AOP将授权逻辑与业务逻辑分开。