使用登陆名存储session 使用session实现用户登录验证

前言

本文学习黑马点评项目，基于Session实现登录校验并分析其中不足之处，后续采用Redis进行改进！

基于Session实现登录流程

 【前端页面流程】

发送验证码：

• 用户在提交手机号后，
• 会校验手机号是否合法，
• 如果不合法，
• 则要求用户重新输入手机号
• 如果手机号合法，后台此时生成对应的验证码，
• 同时将验证码进行保存，然后再通过短信的方式将验证码发送给用户

【实现流程如下】

 

 【UserService】发送验证码代码：

这里的验证码发送到真实手机，需要借助阿里的发送短信服务，因此仅仅为模拟并没有真实发送手机短信

@Override
    public Result sendCode(String phone, HttpSession session) {
        // 1.校验手机号
        if (RegexUtils.isPhoneInvalid(phone)) {
            // 2.如果不符合，返回错误信息
            return Result.fail("手机号格式错误！");
        }
        // 3.符合，生成验证码
        String code = RandomUtil.randomNumbers(6);

        // 4.保存验证码到 session
        session.setAttribute("code",code);
        // 5.发送验证码
        log.debug("发送短信验证码成功，验证码：{}", code);
        // 返回ok
        return Result.ok();
    }

验证码发送成功后点击登录按钮

短信验证码登录、注册：

• 用户将验证码和手机号进行输入，后台从session中拿到当前验证码，然后和用户输入的验证码进行校验，
• 如果不一致，则无法通过校验，
• 如果一致，则后台根据手机号查询用户，
• 如果用户不存在，则为用户创建账号信息，保存到数据库，
• 无论是否存在，都会将用户信息保存到session中，方便后续获得当前登录信息

【登录流程图】

 【UserService】登录代码

@Override
    public Result login(LoginFormDTO loginForm, HttpSession session) {
        // 1.校验手机号
        String phone = loginForm.getPhone();
        if (RegexUtils.isPhoneInvalid(phone)) {
            // 2.如果不符合，返回错误信息
            return Result.fail("手机号格式错误！");
        }
        // 3.校验验证码
        String cacheCode = session.getAttribute("code");
        String code = loginForm.getCode();
        if(cacheCode == null || !cacheCode.equals(code)){
             //3.不一致，报错
            return Result.fail("验证码错误");
        }
        //一致，根据手机号查询用户
        User user = query().eq("phone", phone).one();

        //5.判断用户是否存在
        if(user == null){
            //不存在，则创建
            user =  createUserWithPhone(phone);
        }
        //7.保存用户信息到session中
        session.setAttribute("user",user);

        return Result.ok();
    }

校验登录状态:

• 用户在请求时候，会从cookie中携带者sessionId到后台，
• 后台通过JsessionId从session中拿到用户信息，
• 如果没有session信息，则进行拦截，
• 如果有session信息，则将用户信息保存到threadLocal中，并且放行

【校验流程图】

 由于校验业务需要对很多业务都需要进行校验，因此将其配置为拦截器

 

 【拦截器】代码

public class LoginInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
       //1.获取session
        HttpSession session = request.getSession();
        //2.获取session中的用户
        Object user = session.getAttribute("user");
        //3.判断用户是否存在
        if(user == null){
              //4.不存在，拦截，返回401状态码
              response.setStatus(401);
              return false;
        }
        //5.存在，保存用户信息到Threadlocal
        UserHolder.saveUser((User)user);
        //6.放行
        return true;
    }
}

【拦截器配置类】 

@Configuration
public class MvcConfig implements WebMvcConfigurer {

    @Resource
    private StringRedisTemplate stringRedisTemplate;

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        // 登录拦截器
        registry.addInterceptor(new LoginInterceptor())
                .excludePathPatterns(
                        "/shop/**",
                        "/voucher/**",
                        "/shop-type/**",
                        "/upload/**",
                        "/blog/hot",
                        "/user/code",
                        "/user/login"
                ).order(1);
    }
}

session共享问题

当Tomcat服务器进行集群配置时会出现Session共享问题

核心思路分析：

每个tomcat中都有一份属于自己的session,假设用户第一次访问第一台tomcat，并且把自己的信息存放到第一台服务器的session中，但是第二次这个用户访问到了第二台tomcat，那么在第二台服务器上，肯定没有第一台服务器存放的session，所以此时 整个登录拦截功能就会出现问题，我们能如何解决这个问题呢？早期的方案是session拷贝，就是说虽然每个tomcat上都有不同的session，但是每当任意一台服务器的session修改时，都会同步给其他的Tomcat服务器的session，这样的话，就可以实现session的共享了

但是这种方案具有两个大问题

1、每台服务器中都有完整的一份session数据，服务器压力过大。

2、session拷贝数据时，可能会出现延迟(而且数据重复率较大影响服务器内存)

所以后来采用的方案都是基于redis来完成，我们把session换成redis，redis数据本身就是共享的，就可以避免session共享的问题了