一、认证处理流程说明
原理图
1.在前台输入完用户名密码之后，会进入UsernamePasswordAuthenticationFilter类中去获取用户名和密码，然后去构建一个UsernamePasswordAuthenticationToken对象。
这个对象实现了Authentication接口，Authentication接口封装了验证信息，在调用UsernamePasswordAuthenticationToken的构造函数的时候先调用父类AbstractAuthenticationToken的构造方法，传递一个null，因为在认证的时候并不知道这个用户有什么权限。之后去给用户名密码赋值，最后有一个setAuthenticated（false）方法，代表存进去的信息是否经过了身份认证，源码如下：
2.实例化UsernamePasswordAuthenticationToken之后调用了setDetails(request,authRequest)将请求的信息设到UsernamePasswordAuthenticationToken中去，包括ip、session等内容
3.然后去调用AuthenticationManager,AuthenticationManager本身不包含验证的逻辑，它的作用是用来管理AuthenticationProvider。
authenticate这个方法是在ProviderManager类上的，这个类实现了AuthenticationManager接口，在authenticate方法中有一个for循环，去拿到所有的AuthenticationProvider，真正校验的逻辑是写在AuthenticationProvider中的，为什么是一个集合去进行循环？是因为不同的登陆方式认证逻辑是不一样的，可能是微信等社交平台登陆，也可能是用户名密码登陆。AuthenticationManager其实是将AuthenticationProvider收集起来，然后登陆的时候挨个去AuthenticationProvider中问你这种验证逻辑支不支持此次登陆的方式，根据传进来的Authentication类型会挑出一个适合的provider来进行校验处理。
然后去调用provider的验证方法authenticate方法，authenticate是DaoAuthenticationProvider类中的一个方法，DaoAuthenticationProvider继承了AbstractUserDetailsAuthenticationProvider。实际上authenticate的校验逻辑写在了AbstractUserDetailsAuthenticationProvider抽象类中，首先实例化UserDetails对象，调用了retrieveUser方法获取到了一个user对象，retrieveUser是一个抽象方法。
DaoAuthenticationProvider实现了retrieveUser方法，在实现的方法中实例化了UserDetails对象
也就是相当于自定义验证逻辑的那个类，去实现UserDetailService类，这个返回结果就是我们自己在数据库中根据username查询出来的用户信息。在AbstractUserDetailsAuthenticationProvider中如果没拿到信息就会抛出异常，如果查到了就会去调用preAuthenticationChecks的check方法去进行预检查。
在预检查中进行了三个检查，因为UserDetail类中有四个布尔类型，去检查其中的三个，用户是否锁定、用户是否过期，用户是否可用。
预检查之后紧接着去调用了additionalAuthenticationChecks方法去进行附加检查，这个方法也是一个抽象方法，在DaoAuthenticationProvider中去具体实现，在里面进行了加密解密去校验当前的密码是否匹配。
4.如果通过了预检查和附加检查，还会进行厚检查，检查4个布尔中的最后一个。所有的检查都通过，则认为用户认证是成功的。用户认证成功之后，会将这些认证信息和user传递进去，调用createSuccessAuthentication方法.
在这个方法中同样会实例化一个user，但是这个方法不会调用之前传两个参数的函数，而是会调用三个参数的构造函数。这个时候，在调super的构造函数中不会再传null，会将authorities权限设进去，之后将用户密码设进去，最后setAuthenticated(true),代表验证已经通过。
最后创建一个authentication会沿着验证的这条线返回回去。如果验证成功，则在这条路中调用我们系统的业务逻辑。如果在任何一处发生问题，就会抛出异常，调用我们自己定义的认证失败的处理器。
二、认证结果如何在多个请求之间共享
问题：它是什么时候，把什么东西放到了session中，什么时候在session中读出来。
原理图：
在验证成功之后，其中会调用AbstractAuthenticationFilter中的successfulAuthentication方法，在这个方法最后会调用我们自定义的successHandle登陆成功r处理器，在调用这个方法之前会调用SecurityContextHolder.getContext()的setAuthentication方法，会将我们验证成功的那个Authentication放到SecurityContext中，然后再放到SecurityContextHolder中。SecurityContextImpl中只是重写了hashcode方法和equals方法去保证Authentication的唯一。
SecurityContextHolder是ThreadLocal的一个封装，ThreadLocal是线程绑定的一个map，在同一个线程里在这个方法里往ThreadLocal里设置的变量是可以在另一个线程中读取到的。它是一个线程级的全局变量，在一个线程中操作ThreadLocal中的数据会影响另一个线程。也就是说创建成功之后，塞进去，此次登陆所有的请求都会通过SecurityContextPersisenceFilter去SecurityContextHolder拿那个Authentication。SecurityContextHolder在整个过滤器的最前面。
当请求进来的时候，会先经过SecurityContextPersisenceFilter，SecurityContextPersisenceFilter会去session中去查SecurityContext的验证信息，如果有，就把SecurityContext的验证信息放到线程里直接返回回去，如果没有则通过，去通过其他的过滤器，当请求处理完回来之后，SecurityContextHolder会去检查当前线程中有没有SecurityContext的验证信息，如果有，则将SecurityContext放到session中。通过这样将不同的请求就可以从同一个session里拿到验证信息。
简单来说就是进来的时候检查session，有认证信息放到线程里。出去的时候检查线程，有认证信息放到session里。
因为整个请求和响应的过程都是在一个线程里去完成的，所以在线程的其他位置随时可以用SecurityContextHolder来拿到认证信息。
三、获取认证用户信息
其实使用SecurityContextHolder去获取用户的认证信息的。
我在UserController上加入一个新的接口
@RestController
@RequestMapping("/user")
public class UserController {
@GetMapping("/me")
public Object getCurrentUser(){
return SecurityContextHolder.getContext().getAuthentication();
}
然后我在浏览器里先去登录，然后访问“/user/me”得到用户的身份信息
改进
也可以这样写
@GetMapping("/me")
public Object getCurrentUser(Authentication authentication){
return authentication;
}
同样也可以拿到用户的身份信息，但是如果我只想拿到用户名不想拿到那么多一长串怎么办？
代码可以这样写：
@GetMapping("/me")
public Object getCurrentUser(@AuthenticationPrincipal UserDetails userDetails){
return userDetails;
}
然后重新登录访问：可以看到
其实我只拿到了Principal对象。
