5 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	377429995c	release: freeze V1.2 demo acceptance 2026-10-25	2026-10-25 14:29:29 +08:00
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
WorkBuddy	8dee67040c	fix(miniapp): 幂等键改为按操作稳定；删除指向 404 的互选死代码 ... 1) 幂等键（配合后端机制） 原写法把 Date.now() 拼进幂等键，每次调用都生成新键，即使后端实现了幂等 也永远不会命中 —— 声明端与实现端各自都坏。 api.idempotencyKey(scope, subject)：键缓存在 _pendingIdempotency（TTL 10min）， 同一逻辑操作在成功之前复用同一把键，收到 200+success 才释放；失败（含网络错误） 不释放，下次重试沿用同一把键。25 处调用点（8 个 service + 2 个 TS 页面）全部替换， Date.now 幂等键写法残留经 grep 为 0。 2) 删除死代码 submitInterests 它请求 POST /activities/{id}/interests —— 后端从未实现该端点 （Phase 16 已把表达意向合并进 /activities/{id}/feedback 的 interestTargetUserIds）。全仓确认无任何页面/组件调用方。 两个文件各留注释说明删除原因与恢复条件：若产品确认需要独立的 「提交互选」端点，应先定义语义并补后端实现，再恢复前端方法。 store 头部关于 AGENTS 第 6 条（单向意向保密）的注释同步改为引用 submitFeedback 返回的 newMutuals。	2026-09-18 16:37:33 +08:00
admin	b46b48eb33	chore: establish V1.1 recovery baseline	2026-09-09 22:05:00 +08:00