Question

@RolesAllowed注解和@Secured注解在各个方面基本上都是一致的。唯一显著的区别在于@RolesAllowed是JSR-250定义的Java标准注解。

差异更多在于政治考量而非技术因素。但是，当使用其他框架或API来处理注解的话，使用标准的@RolesAllowed注解会更有意义。

如果选择使用@RolesAllowed的话，需要将@EnableGlobalMethodSecurity的jsr250Enabled属性设置为true，以开启此功能：

尽管我们这里只是启用了jsr250Enabled，但需要说明的一点是这与securedEnabled并不冲突。这两种注解风格可以同时启用。

在将jsr250Enabled设置为true之后，将会启用一个切点，这样带有@RolesAllowed注解的方法都会被Spring Security的切面包装起来。因此，在方法上使用@RolesAllowed的方式与使用@Secured类似。例如，如下的addSpittle()方法使用了@RolesAllowed注解来代替@Secured：

尽管@RolesAllowed比 @Secured在政治上稍微有点优势，它是实现方法安全的标准注解，但是这两个注解有一个共同的不足。它们只能根据用户有没有授予特定的权限来限制方法的调用。在判断方式是否执行方面，无法使用其他的因素。我们在第9章曾经看到过，在保护URL方面，能够使用SpEL表达式克服这一限制。接下来，我们看一下如何组合使用SpEL与Spring Security所提供的方法调用前后注解，实现基于表达式的方法安全性。