不做菜虚困的博客

在基本的通信流程中，我们一般采用Session去存储用户的认证状态。在Spring Security实现用户认证三中讲过，在拿到前端传输过来的用户名和密码之后，会有专门的过滤器处理这部分的需求，并且对认证成功的用户生成Token且存储在Session中。在下次发起请求时，直接从Session中取出同用户名的token进行密码哈希的比较要认证用户。对于无状态认证，则我们的认证不依赖与服务器端存储的Session的状态。所以无状态认证需要我们每次从前端传输一个包含完整认证信息的Token到服务器端进行自定义的认

在[Spring Security实现用户认证一](https://blog.csdn.net/weixin_45248370/article/details/138870258)中说到，请求被过滤器`UsernamePasswordAuthenticationFilter`处理生成`UsernamePasswordAuthenticationToken`，实际上这里的token只是临时的，并没有进行认证，需要一个`AuthenticationProvider`提供认证方式。

注释掉原来的formLogin和httpBasic。@Beanauthorizelogin.loginPage("/login").permitAll() // 一定加上这个，不然会一直重定向，导致报错在resources下创建目录templates，用来存放thymeleaf写的页面，在这个目录下面创建login.html页面。

Spring Security基于过滤器链的概念，可以轻松地集成到任何基于Spring的应用程序中。这样做的坏处是需要维持大量的session，加重了服务器的负担。Spring Security是一个Java框架，用于保护应用程序的安全性。从上面得知，Spring Security内部是由一个个过滤器组成的，那必然会经历一个认证过滤器。默认情况下是保存在session中的，方便下次直接从session中获取（持久化）。，其本质是一个抽象类型的过滤器，通过调用里面一个用于执行认证的抽象方法。