SSO单点登录（Filter过滤器源码解读）

先贴一段代码：

public class UserDetailsServiceImpl implements UserDetailsService {
    @Autowired
    private RemoteUserService remoteUserService;

    /**
     * 基于用户名获取数据库中的用户信息
     *
     * @param username 这个username来自客户端
     * @return
     * @throws UsernameNotFoundException
     */
    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException {
        //基于feign方式获取远程数据并封装
        //1.基于用户名获取用户信息
        User user =
                remoteUserService.selectUserByUsername(username);
        if (user == null)
            throw new UsernameNotFoundException("用户不存在");
        //2.基于用于id查询用户权限
        List<String> permissions =
                remoteUserService.selectUserPermissions(user.getId());
        log.info("permissions {}", permissions);
        //3.对查询结果进行封装并返回
        org.springframework.security.core.userdetails.User userInfo = new org.springframework.security.core.userdetails.User(username, user.getPassword(), AuthorityUtils.createAuthorityList(permissions.toArray(new String[]{})));
        return userInfo;
        //返回给认证中心,认证中心会基于用户输入的密码以及数据库的密码做一个比对
    }
}

 可以从上面这张官方给出的图中看出，我们的代码实现了UserDetailsService这个接口的原因是什么：因为UserDetailService这个接口是被定义在了执行链中。

这篇文章主要看一下DispatchServlet中Filterchain的执行过程，主要解决一下几个疑问：

1.我们知道SSO单点登录的密码校验工作实际上是通过filter以一种拦截的形式实现的，那是哪个具体的Filter实现类实现的？

2.我们知道springmvc的工作流程中，在执行Filterchain中servlet的service方法之前，有一堆过滤器，这些过滤器和使用了单点登录技术的项目中使用的过滤器有什么不同？区别在哪里？

问题1的解答：

通过断点跟踪，我们可以看到，在原始的（任何项目中都存在的）Filterchain中多了一个DelegatingFilterproxy，这个DelegatingFilterproxy其实顾名思义还是一个filterchain，因为它内部封装了下面这一堆filter，然后通过循环迭代的方式调用了这一堆filter，在执行到其中的AbstractAuthenticationProcessingFilter的时候，才最终去调用了我们自己定义的那个UserDetailService的实现类中的方法。

 问题2的解答：

 我们可以看到使用了单点登录技术的项目，在filterchain中有这样一个filter（他其实自身就是一个filterchain）

而一般的mvc项目中，filterchain中的filter只有这些 ，而最关键的是，这些filter在执行完自己的doFilterInternal方法后，都会去调用chain.filter方法，去让filterchain继续执行下去，从而在最后一个filter过滤完之后，执行了servlet的service方法，再去交给DispatchServlet去prehandle再handle再postHandle，而delegatingfilterchain不会。

最后我们探寻一下，这个sso才有的DelegatingFilterproxy到底哪儿来的？哈哈，贱不贱

方法其实也很简单，直接上断点，之后找到了这样一个类DelegatingFilterProxyRegistrationBean，不要问我什么意思我也不知道，只需要知道他是一个applicationfilterconfig，而什么是applicationfilterconfig，他其实就是一个filter的包装类，一个filterconfig可以通过getifilter拿到里面的filter然后去调用doFilterInternal做过滤，而DelegatingFilterproxy就是这个DelegatingFilterProxyRegistrationBean拿出来的filter。

最后的最后，为什么这个DelegatingFilterproxy应该是一个filter，他是如何实现想filterchain那样里面封装多个filter的呢？下一篇文章再探讨