登录逻辑结合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
复制
<div>欢迎，{{username}}</div>运行 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中得到正确的验证码，然后与⽤户输⼊的验证码做⽐较，看是否⼀致。