[黑马点评日志|短信登陆】

实战篇

总结了短信登录功能的实现过程：1）使用Hutool生成验证码并暂存Session；2）验证通过后查询/创建用户，使用BeanUtils脱敏用户信息；3）通过拦截器进行登录校验，并将用户信息存入ThreadLocal；4）采用Redis替代Session解决多Tomcat会话共享问题；5）优化为双拦截器架构，前置拦截器负责Token刷新和用户信息维护。实施过程中需注意验证码绑定、拦截器配置及数据脱敏等关键问题

短信登陆

1.在实现发送验证码功能中，使用Hutool中的RandomUtil.randomNumbers()方法生成验证码，再将其通过session.setAttribute()方法保存到session会话中

问题：没有实现发送验证码，而是通过log.debug方式在控制台输出验证码

2.在实现登陆功能中，将获取到的前端传过来的验证码和session中保存的验证码进行校验，成功则通过使用MyBatis-Plus（这个技术栈我还不太了解）中的方法在MySQL数据库中查询用户，如果不存在则创建用户，存在则直接保存用户信息到session，其中还有个问题，我们不能直接保存user数据类型的数据到会话，因为其中还包含了密码等隐私信息，我们可以通过Hutool中的BeanUtil.copyProperties()方法将User数据类型实体转换成另一个只包含必要信息的数据类型实体。

问题：登陆时手机号和验证码没有绑定关系，可能存在验证码正确但登陆其他人账号的问题（但是后面采用redis键值对的方式保存用户登陆信息就解决了这个问题）

3.在实现登录校验功能中，使用拦截器技术，还是通过得到会话中User的信息判断用户是否存在，不存在则拦截，存在则在放行之前将用户信息保存到ThreadLocal中，方便后面获取当前登录的用户。其中要注意拦截器配置类中的信息不要出错，我就是因为首先没加@Configuration注解，然后配置拦截器忽略的请求路径信息打错了导致登陆不进去一直闪退。

4.通过session保存的登录信息在不同tomcat上不共享，如果通过拷贝的方式共享会话信息的话既浪费内存又存在延时，所以我们采用redis来保存登录信息

5.之前使用单个拦截器刷新token有效期存在一定漏洞，因为只有访问需要登陆的页面时拦截器才会生效，所以我们在这个拦截器前再定义一个拦截器，把刷新token有效期和保存用户信息到ThreadLocal等操作放到这个拦截器中来，后面的拦截器只需要判断ThreadLocal中是否存在用户即可，同时记得配置MvcConfig