登录逻辑结合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

  复制

  欢迎，{{username}}

  运行 HTML

5. 返回 HTML 给浏览器

• 服务端将渲染后的 HTML 页面返回给浏览器。

• 浏览器解析 HTML 并显示内容。

6. 浏览器显示用户信息

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

• 如果用户未登录，页面会显示登录链

3. Cookie 和 Session 的区别

特性	Cookie	Session
存储位置	客户端（浏览器）	服务器端
数据安全性	较低（数据存储在客户端，可能被篡改或窃取）	较高（数据存储在服务器端，客户端只保存 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中得到正确的验证码，然后与⽤户输⼊的验证码做⽐较，看是否⼀致。