《Spring Security3》第五章第四一部分翻译（方法安全的高级知识和小结）（转载）

《Spring Security3》第五章第四部分翻译（方法安全的高级知识和小结）（转载）

?

最后，用Spring XML的语法来声明bean，添加如下的附加的包装，它声明任何想触发changePassword方法的人必须是一个ROLE_USER：

?

像本章前面的其它例子那样，这个保护功能能够很容易地通过将ROLE_USER 改为ROLE_ADMIN并尝试用guest用户账号修改密码来校验。

在背后，这种方式的方法安全保护功能使用了MethodSecurityInterceptor，它被织入到MapBasedMethodSecurityMetadataSource中。拦截器使用它来决定合适的访问ConfigAttributes。不同于可使用SpEL以拥有更强表达能力的@PreAuthorize注解，<protect>声明只能在access属性中有逗号分隔的一系列角色（类似于JSR-250 @RolesAllowed注解）。

可以使用简单的通配符来注明方法名，如，我们可以用如下的方式保护给定bean里所有的set方法：

?

修改这个规则限制只能管理员触发方法是很容易的，但是对我们来说怎样确定用户试图修改的是自己的密码并不清楚。

幸运的是，SpringSecurity方法注解所绑定的SpEL支持更复杂的表达式，包括含有方法参数的表达式。

?


?SpEL变量的应用要通过#前缀。需要注意的很重要一点是，为了使得方法参数的名字能够在运行时得到，调试符号表中的信息必须在编译后保留。启用这个功能的常见方法如下：
?

?

?在理解它的工作原理之前，我们首先看一下@PostFilter注解的处理流程：



?我们可以看到，再次使用了Spring AOP的标准组成，在一个after的AOP处理器中o.s.s.access.expression.method.ExpressionBasedPostInvocationAdvice被执行，为这个增强（advice）被用来过滤目标方法返回的Collection或Array。像@PreAuthorize注解的处理那样，DefaultMethodSecurityExpressionHandler被再次用在这个表达式构建SpEL上下文和求值上。


?现在，我们已将学习方法后过滤的处理过程，让我们回到所使用的进行分类过滤的SpEL表达式上来。简单起见，我们引用Collection作为方法的返回值，但是@PostFilter可以在Collection和Array返回类型的方法中使用。

在大多数情况中，你会发现Collection的事后过滤将会为你节省到处书写的大量模板代码。

注意理解@PostFilter在原理上怎样生效，不像@PreAuthorize，@PostFilter指定了方法行为而不是事先条件。一些追求纯正面向对象的人可能会认为@PostFilter包含在方法注解并不合适，而是这样的过滤应该在一个方法实现中通过代码进行处理。

【Collection过滤的安全性。需要注意的是你的方法实际返回的Collection被修改了。在一些场景下，这并不是合适的行为，所以你需要保证你方法返回的Collection能够被安全地修改。如果返回的Collection是ORM绑定的，这一点尤其重要，因为事后过滤的修改可能会无意间持久化到ORM的数据存储中。】

Spring Security还支持事先过滤Collections方法参数的功能，让我们尝试实现一下。

使用@PreFilter实现事先过滤集合

同@PostFilter一样，要记住传递到方法中的原始Collection会被永久修改。这可能不是合适的行为，所以你要保证调用者能够了解对Collection的修剪在方法调用后是安全的。

到此为止，我们已经介绍到了你在web安全应用开发中所使用到的很多Spring Security重要功能。

如果你一口气读到此处，这是一个很好的时间休息一下，复习我们所学的东西，并花些时间了解实例代码和Spring Security本身的代码。

在接下来的两章中，我们会涵盖高级的自定义和扩展场景，以及Spring Security的访问控制列表（域对象模型）模块。保证是令人兴奋的话题。