FilterSecurityInterceptor也是很重要的一个interceptor，它的作用是对request进行权限判断，允许访问或者抛出accessDenied异常。
这个类继承AbstractSecurityInterceptor，它的代码很多，但是主要的逻辑有两步：（1）查询出request所需的角色；（2）判断用户是否具有该角色从而允许或拒绝
查询request所需角色是从FilterInvocationSecurityMetadataSource中获取的，可以重写这个方法从数据库中获取request所需的角色，但考虑每次请求都访问数据库比较浪费性能，如果url数量不多，可以考虑一次取完。
判断用户是否具有该角色从而允许或拒绝是在AccessDecisionManager的decide方法中执行的。原有逻辑主要是比对request所需角色和用户已有角色，如果匹配，就允许访问，否则拒绝。如果要实现自己的判断逻辑就要重写decide方法。
SpringSecurity的主要思路是在配置文件中配置url的允许访问角色，request时判断当前request所需角色是否和用户已有角色匹配，从而允许登录或者抛出拒绝访问异常。当抛出拒绝访问异常时，前面说的ExceptionTranslationFilter就会起作用了。
思考改变认证方式，将在配置文件中配置url的方式改为从数据库取，方便给角色授权操作。
在数据库中添加功能(权限)表，并和角色建立多对多关系，即一个用户有多个角色，一个角色又有多个权限。
1.登录验证时把用户具有的所有权限(对应URL地址)都添加securitycontext中，配置文件中把所有的URL地址都设置为permitall。然后重写decide方法，比对URL地址和用户允许访问的URL地址，允许访问或者拒绝访问，这个方案需要验证及注意静态文件的过滤。
2.考虑重写FilterInvocationSecurityMetadataSource把所有的url和角色的匹配取出，后面的decide还按原有方式。
这种思路也需要考虑url和角色的关联关系，而且一个url地址对应一个功能，具体实现也比较麻烦。默认方式可以使用pattern，配置也比较简单。所以各有好处，要根据具体情况决定方案。
