首页 > 其他分享 >基于session登陆的演变

基于session登陆的演变

时间:2022-11-26 22:33:16浏览次数:32  
标签:code 演变 user 验证码 phone session 登陆 Result

1. 发送手机验证码:

  提交手机号-检验手机号-生成验证码->保存到session->发送验证码

   public Result sendCode(String phone, HttpSession session) {
        // 1.校验手机号
        Boolean phoneInvalid = RegexUtils.isPhoneInvalid(phone);
        // 2.如果不符合,返回错误信息
        if (!phoneInvalid) {
            return Result.fail("s手机号不正确");
        }
        // 3.符合,生成验证码
        String code = RandomUtil.randomNumbers(6);
        // 4.保存验证码到 session
        session.setAttribute("code",code);
        // 5.发送验证码
        log.info("短信验证码:{}",code);
        // 返回ok
        return Result.ok();
    }

2.  短信验证登陆

提交手机号和验证码-校验验证码-根据手机号查询用户-存在保存到session
-不存在创建新用户,保存在数据库-存入session

 @Override
    public Result login(LoginFormDTO loginForm, HttpSession session) {
        // 1.校验手机号
        String phone = loginForm.getPhone();
        // 2.如果不符合,返回错误信息
        if(phone!=null&&phone.equals(session.getAttribute("phone"))){
            return Result.fail("cuowu");
        }
        // 检验code
        String code = (String) session.getAttribute("code");
        if (code==null || !code.equals(loginForm.getCode())) {
            return Result.fail("cuowu");
        }
        // 4.一致,根据手机号查询用户 select * from tb_user where phone = ?
        User user = query().eq("phone", phone).one();
        // 5.判断用户是否存在
        if(user==null){
            // 6.不存在,创建新用户并保存
          user = createUserWithPhone(phone);
        }
        //保存进session   
        session.setAttribute("user",user);
        // 6.返回
        return Result.ok();
    }

3. 校验登陆状态

 请求携带cookie -从session获取用户-判断用户是否存在-存在保存用户到Threadlocal

                         - 不存在拦截

问: 为什么是Threadlocal
每一个用户访问我们的服务,都是一个独立的线程,每个线程都有自己独立的存储空间

拦截登陆需要一个拦截器:

View Code

新增的拦截器写完,但是还没有生效,需要去配置拦截器,并放过一些不需要拦截的请求。

View Code

3. 用户信息脱敏

由于用户信息user存在session中被全部返回前端,暴露了客户隐私信息,存在session也造成了存储压力,定义UserDTO,只保存有需要的信息。

4. 当服务使用集群时,存在session共享问题,sessions是存在tomcat中,多台tomcat的session不共存。 这时我们需要换一种替代的方式,替代品需要以下特点:

共享、高性能(使用频率很高所以,所以读写速度要快)、高可用、key-value结构  ======》redis

存储在公共空间又需要保证每个用户唯一key,且客户端需要能够携带。一般是随机的字符串token作为登陆凭证

保存对象到redis 也需要考虑使用什么数据结构,String类型即将对象转化为json字符串存,有点是直观,缺点是更新需要全部更新,且占用内存比hash大

hash 可以对对象的每个字段单独存储,可以对单条属性CRUD,且占用内存小

View Code

 

6. redis 的key越来越多需要设置过期时间, 给token设置过期时间,  这里有两个问题:1 . stringRedisTemplate 如何注入。 2. 如何取到redis Hash接口的对象。

View Code

7. 后续的持续的界面操作需要刷新过期时间避免使用中过期,那么什么时候刷新呢,仅在需要登陆的位置刷新吗? 所有的页面操作都是需要刷新的。怎么做呢,加一层拦截器,所有操作都刷新登陆信息。 

思路,添加一个拦截所有请求的拦截器用来重置token过期时间,

View Code

 

标签:code,演变,user,验证码,phone,session,登陆,Result
From: https://www.cnblogs.com/kisshappyboy/p/16928515.html

相关文章