6 浏览器
全部流程
- 用户登录 用户在客户端输入用户名和密码，客户端将这些信息发送到服务器。
- 服务器验证 服务器收到登录请求后，验证用户凭据。验证通过后，服务器生成一个JWT。
- 生成JWT
- 头部（Header）：包含令牌类型和签名算法
- 载荷（Payload）：包含用户信息，如用户ID、角色、过期时间等
- 签名（Signature）：服务器使用密钥对头部和载荷进行签名，确保数据完整性。
- 返回JWT 服务器将生成的JWT返回给客户端。
- 客户端存储JWT 客户端收到JWT后，通常存储在
localStorage、sessionStorage或Cookie中。 - 后续请求 客户端在每次请求受保护的资源时，将JWT放在HTTP请求的
Authorization头部中，格式为Bearer <JWT>。 - 服务器验证JWT 服务器收到请求后，验证JWT的签名和有效期。验证通过后，从载荷中获取用户信息，授权访问资源。
作用
- 身份认证 通过JWT确认用户身份，无需每次请求都查询数据库。
- 无状态性 服务器不需要存储用户状态，减轻负担，易于扩展。
- 跨域支持 适用于前后端分离和分布式系统。
- 安全性 使用签名算法，确保数据在传输过程中不被篡改。
- 信息传递 可以在载荷中携带少量业务信息，减少数据库查询。
协商缓存和强制缓存
协商缓存
浏览器在请求资源时会发送请求和资源的标识，服务器收到请求和资源标识后判断该资源是否为最新资源，如果不是则返回200状态码以及最新的资源和新的标识，浏览器收到后会将资源缓存在本地缓存中，后续再次请求时依旧带有新的资源标识，如果服务器判断该资源标识是最新资源则会返回304状态码，不携带任何资源，浏览器收到304响应后会直接从本地缓存中拿资源 
强制缓存
当浏览器向服务器拿资源时，服务器会将它认为需要缓存的资源（通常是cs，js，图片等）在头部加上cache-control字段max-age标识生效时间，标识出该资源需要缓存，和缓存生效的时间，浏览器收到响应后会把资源存储在本地的缓存中，后续再次请求该资源时会先去本地缓存检查是否有该资源以及时间是否过期，如果有该资源且没有过期就会直接从本地缓存中拿资源，返回的状态码是：200（from memory cache） 强制缓存的过程中前端不需要做任何处理 
cookie、session、token
cookie
用户登录时将用户名和密码发送给服务器，服务器接收到验证成功后会将用户名存储在set-cookie的请求头发送给浏览器，同时记录该用户的登录状态，浏览器收到响应携带的用户名时会将其存储在cookie中，后续的请求都会携带cookie
- 存储在客户端
- 帮助在客户端和服务器之间维护状态信息
- 安全风险：有被串改风险
- 容量限制：4KB
- 可用限制：用户可能禁用
session
session是存储在服务器的 用户登录后服务器会根据用户的信息生成sessionid，并将其放在响应头的set-cookie字段中，浏览器收到响应后会将sessionid存储在cookie中，后续的每次发送请求都会携带sessionid，服务器会对其进行校验
用户拿不到其中的用户信息
- 安全性高：存储在服务器端
- 容量大：可以保存对象
- 占用服务器资源
- 扩展性差（分布式集群）
- 依然需要依赖cookie跨域限制
token
jwt分为三段，分别是header（算法和token类型）、payload（数据载荷）、signature（header+payload+私钥通过header中指定的算法来加密） 用户可以拿到token通过截取第二段解密来拿到用户数据，但是无法修改
用户登录后服务器进行校验，鉴权成功就会创建jwt令牌，发送给用户，用户拿到token后可以截取第二段并通过base64解码就可以拿到用户信息，但无法修改，后续在使用时可以将token存储在与后端约定的请求头属性（通常是Authorization）发送给后端，后端收到请求时会验证token有没有被篡改，如果没有被篡改就会进行放行
后端是可以解析tokne的，私钥可以被任何集群服务器知晓，来验证
cookie 用户存储账号和密码 session 服务器存储账户和密码 token 传输对象存储账户和密码
| 特性 | localStorage | sessionStorage | cookie |
|---|---|---|---|
| 生命周期 | 永久保存（除非手动清除） | 页面会话期间有效（关闭页面/标签页后清除） | 可以设置过期时间，默认是会话级别 |
| 作用域 | 同源（同协议 + 同域名 + 同端口） | 同源且同一窗口/标签页 | 同域名及路径下可访问 |
| 是否随请求发送到服务器 | 不会自动发送 | 不会自动发送 | 默认每次请求都会携带 |
| 存储容量 | 约 5MB~10MB | 约 5MB~10MB | 单个 cookie 约 4KB，总量受限制 |
| 操作方式 | JavaScript API | JavaScript API | JavaScript 或 HTTP headers |
| 安全性 | 易受 XSS 攻击 | 易受 XSS 攻击 | 可被设置为 HttpOnly 防止 XSS |
| 应用场景 | 用户偏好、本地缓存等 | 临时数据、页面间通信 | 身份验证、服务端状态管理 |
Token过期时的处理
1. 重新登录
适用场景：最简单直接的方式，适用于Token完全失效且无法刷新的情况。 处理步骤：
- 检测到Token过期后，清除本地存储的Token。
- 跳转到登录页面，提示用户重新输入凭据进行登录。
- 登录成功后，获取新的Token并继续之前的操作。
2. 使用刷新Token机制
适用场景：提升用户体验，避免频繁重新登录。 处理步骤：
- 登录时获取Access Token和Refresh Token： 用户登录成功后，服务器返回一个短期有效的Access Token和一个长期有效的Refresh Token。
- 请求时携带Access Token： 每次发送请求时，在请求头中携带Access Token进行身份验证。
- 检测到Access Token过期： 在响应拦截器中捕获返回的Token过期错误（如HTTP状态码401或特定的错误信息）。
- 使用Refresh Token获取新Token： 如果检测到Access Token过期，使用Refresh Token向服务器请求新的Access Token。 服务器验证Refresh Token的有效性，若有效，返回新的Access Token。
- 更新并继续请求： 更新本地存储的Access Token。 重新发送之前因Token过期而失败的请求。
- 处理Refresh Token过期： 如果Refresh Token也过期，清除所有Token，引导用户重新登录。
3. 滑动窗口机制
适用场景：用户持续活跃的情况下，保持Token的有效性。 处理步骤：
- 服务器在每次验证Token有效时，自动延长Token的过期时间。
- 只要用户持续访问，Token就会一直有效，无需重新登录或刷新。
4. 前端检测与处理
设置Token过期时间：
- 在获取Token时，记录其过期时间。
- 在发送请求前，检查Token是否即将过期。 自动刷新Token：
- 如果Token即将过期，在用户无感知的情况下自动使用Refresh Token刷新Access Token。
5. 优化用户体验
友好提示：
- 在Token即将过期时，弹出提示框提醒用户。
- 避免直接中断用户操作，提供继续操作的选项。 无缝切换：
- 在刷新Token期间，保持页面状态，避免页面跳转或刷新。
6. 安全考虑
保护Refresh Token：
- 将Refresh Token存储在安全的本地存储中，避免存储在Cookie或容易被篡改的位置。
- 使用HTTPS协议传输敏感信息。 防止重复刷新：
- 在刷新Token时，设置标志位防止多次重复请求。
- 处理并发请求，避免因Token过期导致的混乱。
7. 日志与监控
记录Token状态：
- 记录Token的生成、使用和过期情况。
- 监控Token的有效期和刷新频率，及时发现潜在问题。
通过以上方法，可以有效处理Token过期的情况，提升系统的安全性和用户体验。具体采用哪种方式，应根据业务需求和实际情况进行选择。
贡献者
pinkdopeybug版权所有
版权归属：
