Question

如果我们希望使用表达式来保护方法的话，那使用@PreAuthorize和@PostAuthorize是非常好的方案。但是，有时候限制方法调用太严格了。有时，需要保护的并不是对方法的调用，需要保护的是传入方法的数据和方法返回的数据。

例如，我们有一个名为getOffensiveSpittles()的方法，这个方法会返回标记为具有攻击性的Spittle列表。这个方法主要会给管理员使用，以保证Spittr应用中内容的和谐。但是，普通用户也可以使用这个方法，用来查看他们所发布的Spittle有没有被标记为具有攻击性。这个方法的签名大致如下所示；

按照这种方法的定义，getOffensiveSpittles()方法与具体的用户并没有关联。它只会返回攻击性Spittle的一个列表，并不关心它们属于哪个用户。对于管理员使用来说，这是一个很好的方法，但是它无法限制列表中的Spittle都属于当前用户。

当然，我们也可以重载getOffensiveSpittles()，实现另一个版本，让它接受一个用户ID作为参数，查询给定用户的Spittle。但是，正如我在本章开头所讲的那样，始终会有这样的可能性，那就是将较为宽松限制的版本用在具有一定安全限制的场景中。^[1]

我们需要有一种方式过滤getOffensiveSpittles()方法返回的Spittle集合，将结果限制为允许当前用户看到的内容，而这就是Spring Security的@PostFilter所能做的事情。我们来试一下。

事后对方法的返回值进行过滤

与@PreAuthorize和@PostAuthorize类似，@PostFilter也使用一个SpEL作为值参数。但是，这个表达式不是用来限制方法访问的，@PostFilter会使用这个表达式计算该方法所返回集合的每个成员，将计算结果为false的成员移除掉。

为了阐述该功能，我们将@PostFilter应用在getOffensiveSpittles()方法上：

在这里，@PreAuthorize限制只有具备ROLE_SPITTER或ROLE_ADMIN权限的用户才能访问该方法。如果用户能够通过这个检查点，那么方法将会执行，并且会返回Spittle所组成的一个List。但是，@PostFilter注解将会过滤这个列表，确保用户只能看到允许的Spittle。具体来讲，管理员能够看到所有攻击性的Spittle，非管理员只能看到属于自己的Spittle。

表达式中的filterObject对象引用的是这个方法所返回List中的某一个元素（我们知道它是一个Spittle）。在这个Spittle对象中，如果Spitter的用户名与认证用户（表达式中的principal.name）相同或者用户具有ROLE_ADMIN角色，那这个元素将会最终包含在过滤后的列表中。否则，它将被过滤掉。

事先对方法的参数进行过滤

除了事后过滤方法的返回值，我们还可以预先过滤传入到方法中的值。这项技术不太常用，但是在有些场景下可能会很便利。

例如，假设我们希望以批处理的方式删除Spittle组成的列表。为了完成该功能，我们可能会编写一个方法，其签名大致如下所示：

看起来很简单，对吧？但是，如果我们想在它上面应用一些安全规则的话，比如Spittle只能由其所有者或管理员删除，那该怎么做呢？如果是这样的话，我们可以将逻辑放在deleteSpittles()方法中，在这里循环列表中的Spittle，只删除属于当前用户的那一部分对象（如果当前用户是管理员的话，则会全部删除）。

这能够运行正常，但是这意味着我们需要将安全逻辑直接嵌入到方法之中。相对于删除Spittle来讲，安全逻辑是独立的关注点（当然，它们也有所关联）。如果列表中能够只包含实际要删除的Spittle，这样会更好一些，因为这能帮助deleteSpittles()方法中的逻辑更加简单，只关注于删除Spittle的任务。

Spring Security的@PreFilter注解能够很好地解决这个问题。与@PostFilter非常类似，@PreFilter也使用SpEL来过滤集合，只有满足SpEL表达式的元素才会留在集合中。但是它所过滤的不是方法的返回值，@PreFilter过滤的是要进入方法中的集合成员。

@PreFilter的使用非常简单。如下的deleteSpittles()方法使用了@PreFilter注解：

与前面一样，对于没有ROLE_SPITTER或ROLE_ADMIN权限的用户，@PreAuthorize注解会阻止对这个方法的调用。但同时，@PreFilter注解能够保证传递给deleteSpittles()方法的列表中，只包含当前用户有权限删除的Spittle。这个表达式会针对集合中的每个元素进行计算，只有表达式计算结果为true的元素才会保留在列表中。targetObject是Spring Security提供的另外一个值，它代表了要进行计算的当前列表元素。

Spring Security提供了注解驱动的功能，这是通过一系列注解来实现的，到此为止，我们已经对这些注解进行了介绍。相对于判断用户所授予的权限，使用表达式来定义安全限制是一种更为强大的方式。

即便如此，我们也不应该让表达式过于聪明智能。我们应该避免编写非常复杂的安全表达式，或者在表达式中嵌入太多与安全无关的业务逻辑。而且，表达式最终只是一个设置给注解的String值，因此它很难测试和调试。

如果你觉得自己的安全表达式难以控制了，那么就应该看一下如何编写自定义的许可计算器（permission evaluator），以简化你的SpEL表达式。下面我们看一下如何编写自定义的许可计算器，用它来简化之前用于过滤的表达式。

定义许可计算器

我们在@PreFilter和@PostFilter中所使用的表达式还算不上太复杂。但是，它也并不简单，我们可以很容易地想象如果还要实现其他的安全规则，这个表达式会不断膨胀。在变得很长之前，表达式就会笨重、复杂且难以测试。

其实我们能够将整个表达式替换为更加简单的版本，如下所示：

现在，设置给@PreFilter的表达式更加紧凑。它实际上只是在问一个问题“用户有权限删除目标对象吗？”。如果有的话，表达式的计算结果为true，Spittle会保存在列表中，并传递给deleteSpittles()方法。如果没有权限的话，它将会被移除掉。

但是，hasPermission()是哪来的呢？它的意思是什么？更为重要的是，它如何知道用户有没有权限删除targetObject所对应的Spittle呢？

hasPermission()函数是Spring Security为SpEL提供的扩展，它为开发者提供了一个时机，能够在执行计算的时候插入任意的逻辑。我们所需要做的就是编写并注册一个自定义的许可计算器。程序清单14.1展现了SpittlePermissionEvaluator类，它就是一个自定义的许可计算器，包含了表达式逻辑。

程序清单14.1　许可计算器为hasPermission()提供实现逻辑

SpittlePermissionEvaluator实现了Spring Security的PermissionEvaluator接口，它需要实现两个不同的hasPermission()方法。其中的一个hasPermission()方法把要评估的对象作为第二个参数。第二个hasPermission()方法在只有目标对象的ID可以得到的时候才有用，并将ID作为Serializable传入第二个参数。

为了满足我们的需求，我们假设使用Spittle对象来评估权限，所以第二个方法只是简单地抛出UnsupportedOperationException。

对于第一个hasPermission()方法，要检查所评估的对象是否为一个Spittle，并判断所检查的是否为删除权限。如果是这样，它将对比Spitter的用户名是否与认证用户的名称相等，或者当前用户是否具有ROLE_ADMIN权限。

许可计算器已经准备就绪，接下来需要将其注册到Spring Security中，以便在使用@PreFilter表达式的时候支持hasPermission()操作。为了实现该功能，我们需要替换原有的表达式处理器，换成使用自定义许可计算器的处理器。

默认情况下，Spring Security会配置为使用DefaultMethodSecurityExpression-Handler，它会使用一个DenyAllPermissionEvaluator实例。顾名思义，Deny-AllPermissionEvaluator将会在hasPermission()方法中始终返回false，拒绝所有的方法访问。但是，我们可以为Spring Security提供另外一个DefaultMethod-SecurityExpressionHandler，让它使用我们自定义的SpittlePermissionEvaluator，这需要重载GlobalMethodSecurityConfiguration的createExpressionHandler方法：

现在，我们不管在任何地方的表达式中使用hasPermission()来保护方法，都会调用SpittlePermissionEvaluator来决定用户是否有权限调用方法。