登录逻辑联合redis

1. 用户登录

  

• 用户访问登录页面，输入用户名和密码，提交表单。
  
• 服务端验证用户名和密码：
  
  
  
  • 如果验证成功，天生 ticket，并将 ticket 和用户 ID 存储在缓存中（如 Redis）。
    
  • 将 ticket 放入 Cookie 中，设置 Cookie 的有效期（如 7 天）。
    
  • 返反响应给浏览器，浏览器存储 Cookie。
    
  
  

  2. 浏览器存储 Cookie

  

• 浏览器收到响应后，将 Cookie 存储在本地。
  
• 下次访问时，浏览器会自动将 Cookie 附加到请求头中，发送给服务端。
  

  3. 拦截器处理请求

  

• 拦截器从请求的 Cookie 中提取 ticket：
  
  
  
  • 如果 ticket 不存在或无效，跳转到登录页面。
    
  • 如果 ticket 有效，从缓存中查询对应的用户 ID。
    
  • 通过用户 ID 查询用户信息（如用户名、头像等）。
    
  • 将用户信息放入 Model 中。
    
  
  

  4. 模板引擎渲染 HTML

  

• 模板引擎根据 Model 中的数据，动态天生 HTML 页面。
  
• 比方，如果 Model 中包含用户信息，模板引擎会天生类似以下的 HTML：
  html
  复制
  
  1. <div>欢迎，{{username}}</div>

  复制代码
  运行 HTML
  

  5. 返回 HTML 给浏览器

  

• 服务端将渲染后的 HTML 页面返回给浏览器。
  
• 浏览器分析 HTML 并显示内容。
  

  6. 浏览器显示用户信息

  

• 如果用户已登录，页面会显示用户的登录信息（如“欢迎，用户名”）。
  
• 如果用户未登录，页面会显示登录链
  

  
  
  
  3. Cookie 和 Session 的区别

  特性CookieSession存储位置客户端（浏览器）服务器端数据安全性较低（数据存储在客户端，可能被篡改或窃取）较高（数据存储在服务器端，客户端只生存 ID）存储巨细较小（通常不凌驾 4KB）较大（受服务器内存或存储限制）性能影响无（数据存储在客户端）有（数据存储在服务器端，可能占用资源）生命周期可设置有效期（浏览器关闭后仍可保留）通常随浏览器关闭或超时失效适用场景存储少量非敏感数据（如用户偏好设置）存储敏感数据（如用户登录状态）  
  
  
  
  4. 为什么选择 Cookie 或 Token 而不是 Session

  （1）分布式系统的需求

  

• 现代应用通常是分布式的，用户的请求可能被分发到差别的服务器。
  
• 使用 Session 需要在多个服务器之间共享数据，而 Cookie 或 Token 是无状态的，更得当分布式系统。
  

  （2）性能优化

  

• Session 需要频繁访问数据库或缓存，而 Cookie 或 Token 只需验证其有效性，性能更高。
  

  （3）简化架构

  

• 使用 Cookie 或 Token 可以制止引入复杂的 Session 管理机制（如分布式缓存），简化系统架构。
  

  （4）安全性

  

• Cookie 可以通过 HttpOnly 和 Secure 标志增强安全性。
  
• Token（如 JWT）可以通过签名和加密包管数据的完备性和安全性。
  

  使⽤Redis存储验证码 当⽤户点击革新验证码时，服务端⾸先给当前需要登陆的游客，设置⼀个随机字符串(kaptchaOwner)，⽤于标识 当前这个游客，然后将随机字符串存⼊到cookie中，返回给浏览器，然后服务端的redis生存 key:随机字符串, value:验证码 。 接着⽤户输⼊⽤户名，密码，验证码，再次点击登陆时，服务端会从cookie中拿到kaptchaOwner,通过它，可以从 Redis中得到正确的验证码，然后与⽤户输⼊的验证码做⽐较，看是否⼀致。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。