danyang-match

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
WorkBuddy	825fd41ee4	fix(auth): 修复刷新令牌链路三层断点，并把 121 处裸异常收敛为携带 HTTP 语义的异常用户在微信开发者工具里看到首页全站 401，追下去发现「刷新」这条路整条是断的，且断在三个互不相干的地方 —— 每修好一层，下一层才显形： 1) 前端漏传 userId → /auth/refresh 直接 400（上一笔 `63c18d8` 已修） 2) 后端把 refresh token 交给 validateToken 校验，而那是用 access 密钥验签的， refresh token 由 refresh 密钥签发 → 必然失败。这是本次的核心修复。 3) 失败被抛成裸 RuntimeException → HTTP 500，客户端当作服务端故障重试。 4) 换发出来的新 refresh token 与旧 token 逐字节相同 —— JWT 的 iat 只有秒级精度、且未设 jti，同一用户同一秒内签发的令牌完全一致，「刷新即轮换、旧令牌作废」这条安全属性形同不存在（Redis 比对旧值自然相等）。三处签发补 UUID jti。第 2 层此前被两层掩盖：前端漏传 userId 使请求先 400 走不到验签；且全仓没有任何 /auth/refresh 用例。第 4 层则只在「同一秒内签发两次」时才暴露，是新增 E2E 用例（换发后立刻用旧令牌再刷一次）把它逼出来的。同时修复审计中发现的同族问题： - AnalyticsService 用的是 shared.exception.BusinessException，而全局处理器只映射嵌套类 GlobalExceptionHandler.BusinessException —— 该异常无任何 handler，直落 500。现让旧类继承被映射的类，从结构上杜绝「未映射的业务异常静默 500」。 - 小程序 authStore 读 result.needPhone，后端返回 isNewUser → `!undefined === true`，每个用户一登录就被标记成已绑手机号。同族的第三个字段名不一致缺陷。 - 小程序 api.js 的 401 分支会无条件触发 onSessionExpired→refresh；后端把刷新失败语义修正为 401 后，这条路径会自我递归。补 /auth/* 守卫。 - 登录页只认 instanceof Error，把服务端文案（如「账号已被封禁」）丢了。后端异常收敛（121 处 → 0）： - 业务拒绝改抛 BusinessException + ApiResponseCode（404 不存在 / 403 无权与状态不允许 / 409 冲突重复 / 400 参数非法），文案一字未改，避免测试与前端文案契约漂移 - 真正的服务端故障（加解密、文件头、上传、签名、实名 Provider）改为显式 ServerErrorException：仍是 500，但意图明确、ERROR 记全栈、不向客户端泄露内部细节 - 用带显式映射表的脚本执行（fail-closed，遇未知文案即中止），不用启发式规则守卫（先有判别力再谈全绿）： - 新增 JwtTokenServiceRefreshTokenTest：钉住「refresh 用 refresh 密钥验签」与「两类令牌不得互相顶替」（含两把密钥被配成同值时的 type 声明兜底），以及「同一秒内签发的两个令牌必须逐字节不同」 - 新增 RuntimeExceptionThrowGuardTest：扫源码断言 main 零裸抛（无白名单副本） - GlobalExceptionHandlerTest 补三条：别名的实例必须按其业务码回 403 而非 500、无法识别的字符串码 fail-closed 到 500（不得退化成无信息的 400）、以及继承关系守卫（把别名类改回 RuntimeException 会静默恢复该缺陷，只有它能咬住） - 新增 tests/e2e/auth_refresh_test.py：唯一覆盖 /auth/refresh 的用例，断言换发的 accessToken 真能过鉴权、旧令牌轮换失效、无效凭据 401 而非 500 - http_semantics_test.py 补「Service 层拒绝必须是 4xx 而非 5xx」 - miniapp-auth-contracts.mjs 补 isNewUser 映射（双向）与 /auth/* 401 不递归验证： - 定向后端测试 9/9 - 全量后端测试 113 个测试类、0 失败、BUILD SUCCESS - 本机真实栈 E2E 72 passed（含 7 个新增刷新用例） - miniapp tsc 0 错误、UI 契约门控 18/18 - 负向注入两处精准变红（RuntimeExceptionThrowGuardTest 与 JwtTokenServiceRefreshTokenTest 各 1 例），BUILD FAILURE，注入前后工作区 SHA256 逐字节一致（零污染）	2026-09-22 21:41:30 +08:00
WorkBuddy	63c18d89c2	fix(miniapp): 修复全站 401 —— 认证链字段名不一致 + 首页 onRetry 缺失根因（读码 + 本机后端实测坐实）： - 后端登录/刷新返回 accessToken，前端 authStore 却读 result.token → accessToken 从未落库 → 每个请求都不带 Authorization → 全站 401（首页无法加载）。 - /auth/refresh 少传 userId：后端以 userId 定位 Redis refresh token，缺失即 BAD_REQUEST → HTTP 400（实测 {refreshToken} 体 → 400）。 - 首页 index.wxml 绑定 bind:retry="onRetry"（ui-error-state 触发 retry 事件），但 index.ts 无该方法 → 控制台报错、错误页「重新加载」失效。 - app.globalData.token 从未赋值，多页直读它拼 Authorization → Bearer undefined。修复： - authStore：登录/刷新改用 result.accessToken；刷新传 this.state.userId。 - authService.refresh(userId)：发送 { userId, refreshToken }。 - pages/index：新增 onRetry；onLoad 订阅 authStore（expired → 回登录引导；刷新成功且停在错误态 → 自动重载）；onUnload 退订。 - utils/api：saveToken/clearToken/getToken 同步 app.globalData.token，兼容旧页面。守卫补强： - ui-tests/miniapp-auth-contracts.mjs 原仅覆盖 hydrate，对字段名缺陷零覆盖。新增行为断言：登录后 storage.accessToken 必须等于后端 accessToken；刷新请求体必须含 userId + refreshToken 并持久化新 accessToken。已双向负向注入验证判别力（改回 result.token / 去掉 userId 均 exit 1）。验证： - tsc --noEmit -p miniapp/tsconfig.json → exit 0，零错误。 - scripts/run-ui-contracts.mjs → 18/18 PASS。 - 本机 8085 /auth/refresh 三态实测：{} → 400；{refreshToken} → 400； {userId,refreshToken} → 500（进入服务校验，非 400）。 - 未验证：开发者工具内实际登录→首页链路（本机无法驱动 devtools，待用户复测）。	2026-09-22 19:08:16 +08:00
admin	c20301ffff	fix: restore miniapp public startup flows	2026-09-10 22:57:52 +08:00

825fd41ee4

fix(auth): 修复刷新令牌链路三层断点，并把 121 处裸异常收敛为携带 HTTP 语义的异常

用户在微信开发者工具里看到首页全站 401，追下去发现「刷新」这条路整条是断的，
且断在三个互不相干的地方 —— 每修好一层，下一层才显形：

1) 前端漏传 userId → /auth/refresh 直接 400（上一笔 63c18d8 已修）
2) 后端把 refresh token 交给 validateToken 校验，而那是用 access 密钥验签的，
   refresh token 由 refresh 密钥签发 → 必然失败。这是本次的核心修复。
3) 失败被抛成裸 RuntimeException → HTTP 500，客户端当作服务端故障重试。
4) 换发出来的新 refresh token 与旧 token **逐字节相同** —— JWT 的 iat 只有秒级精度、
   且未设 jti，同一用户同一秒内签发的令牌完全一致，「刷新即轮换、旧令牌作废」
   这条安全属性形同不存在（Redis 比对旧值自然相等）。三处签发补 UUID jti。

第 2 层此前被两层掩盖：前端漏传 userId 使请求先 400 走不到验签；且全仓
没有任何 /auth/refresh 用例。第 4 层则只在「同一秒内签发两次」时才暴露，
是新增 E2E 用例（换发后立刻用旧令牌再刷一次）把它逼出来的。

同时修复审计中发现的同族问题：
- AnalyticsService 用的是 shared.exception.BusinessException，而全局处理器只映射
  嵌套类 GlobalExceptionHandler.BusinessException —— 该异常无任何 handler，直落 500。
  现让旧类继承被映射的类，从结构上杜绝「未映射的业务异常静默 500」。
- 小程序 authStore 读 result.needPhone，后端返回 isNewUser → `!undefined === true`，
  每个用户一登录就被标记成已绑手机号。同族的第三个字段名不一致缺陷。
- 小程序 api.js 的 401 分支会无条件触发 onSessionExpired→refresh；后端把刷新失败
  语义修正为 401 后，这条路径会自我递归。补 /auth/* 守卫。
- 登录页只认 instanceof Error，把服务端文案（如「账号已被封禁」）丢了。

后端异常收敛（121 处 → 0）：
- 业务拒绝改抛 BusinessException + ApiResponseCode（404 不存在 / 403 无权与状态不允许 /
  409 冲突重复 / 400 参数非法），文案一字未改，避免测试与前端文案契约漂移
- 真正的服务端故障（加解密、文件头、上传、签名、实名 Provider）改为显式
  ServerErrorException：仍是 500，但意图明确、ERROR 记全栈、不向客户端泄露内部细节
- 用带显式映射表的脚本执行（fail-closed，遇未知文案即中止），不用启发式规则

守卫（先有判别力再谈全绿）：
- 新增 JwtTokenServiceRefreshTokenTest：钉住「refresh 用 refresh 密钥验签」与
  「两类令牌不得互相顶替」（含两把密钥被配成同值时的 type 声明兜底），
  以及「同一秒内签发的两个令牌必须逐字节不同」
- 新增 RuntimeExceptionThrowGuardTest：扫源码断言 main 零裸抛（无白名单副本）
- GlobalExceptionHandlerTest 补三条：别名的实例必须按其业务码回 403 而非 500、
  无法识别的字符串码 fail-closed 到 500（不得退化成无信息的 400）、
  以及继承关系守卫（把别名类改回 RuntimeException 会静默恢复该缺陷，只有它能咬住）
- 新增 tests/e2e/auth_refresh_test.py：唯一覆盖 /auth/refresh 的用例，
  断言换发的 accessToken 真能过鉴权、旧令牌轮换失效、无效凭据 401 而非 500
- http_semantics_test.py 补「Service 层拒绝必须是 4xx 而非 5xx」
- miniapp-auth-contracts.mjs 补 isNewUser 映射（双向）与 /auth/* 401 不递归

验证：
- 定向后端测试 9/9
- 全量后端测试 113 个测试类、0 失败、BUILD SUCCESS
- 本机真实栈 E2E 72 passed（含 7 个新增刷新用例）
- miniapp tsc 0 错误、UI 契约门控 18/18
- 负向注入两处精准变红（RuntimeExceptionThrowGuardTest 与
  JwtTokenServiceRefreshTokenTest 各 1 例），BUILD FAILURE，
  注入前后工作区 SHA256 逐字节一致（零污染）

2026-09-22 21:41:30 +08:00

WorkBuddy

63c18d89c2

fix(miniapp): 修复全站 401 —— 认证链字段名不一致 + 首页 onRetry 缺失

根因（读码 + 本机后端实测坐实）：
- 后端登录/刷新返回 accessToken，前端 authStore 却读 result.token →
  accessToken 从未落库 → 每个请求都不带 Authorization → 全站 401（首页无法加载）。
- /auth/refresh 少传 userId：后端以 userId 定位 Redis refresh token，
  缺失即 BAD_REQUEST → HTTP 400（实测 {refreshToken} 体 → 400）。
- 首页 index.wxml 绑定 bind:retry="onRetry"（ui-error-state 触发 retry 事件），
  但 index.ts 无该方法 → 控制台报错、错误页「重新加载」失效。
- app.globalData.token 从未赋值，多页直读它拼 Authorization → Bearer undefined。

修复：
- authStore：登录/刷新改用 result.accessToken；刷新传 this.state.userId。
- authService.refresh(userId)：发送 { userId, refreshToken }。
- pages/index：新增 onRetry；onLoad 订阅 authStore（expired → 回登录引导；
  刷新成功且停在错误态 → 自动重载）；onUnload 退订。
- utils/api：saveToken/clearToken/getToken 同步 app.globalData.token，兼容旧页面。

守卫补强：
- ui-tests/miniapp-auth-contracts.mjs 原仅覆盖 hydrate，对字段名缺陷零覆盖。
  新增行为断言：登录后 storage.accessToken 必须等于后端 accessToken；
  刷新请求体必须含 userId + refreshToken 并持久化新 accessToken。
  已双向负向注入验证判别力（改回 result.token / 去掉 userId 均 exit 1）。

验证：
- tsc --noEmit -p miniapp/tsconfig.json → exit 0，零错误。
- scripts/run-ui-contracts.mjs → 18/18 PASS。
- 本机 8085 /auth/refresh 三态实测：{} → 400；{refreshToken} → 400；
  {userId,refreshToken} → 500（进入服务校验，非 400）。
- 未验证：开发者工具内实际登录→首页链路（本机无法驱动 devtools，待用户复测）。

2026-09-22 19:08:16 +08:00

admin c20301ffff fix: restore miniapp public startup flows 2026-09-10 22:57:52 +08:00