5 Commits

Include renames

Author	SHA1	Message	Date
WorkBuddy	3c2b967274	release: freeze 2026-10-15 validated release baseline	2026-10-15 09:47:31 +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	af5412646b	test(e2e): 运营登录只用 seed 账号；补幂等 E2E 与两处机械守卫 ... 1) 修复一处从未暴露的 CI 缺陷 库中 operator 账号没有任何迁移种子，DemoDataSeeder 也不创建运营账号 （只统计数量），全新库唯一的账号来源是 seed_e2e_operators.sql。 而 conftest 的 admin_token 写死 username="admin" —— 那是某台开发机上 手工创建的遗留账号：本机有它所以本地一直跑绿，CI 全新库没有它 → 该 fixture 必然 401 → e2e job 从未真正通过过。 同一文件里「外加迁移 seed 的 admin」这句注释也是纯粹的虚构。 改用 seed 创建的 e2e_admin（已绑定 super_admin，语义等价）。 2) fixture_account_guard_test.py（2 用例） 机械拦住「fixture 依赖本机手工数据」：从 seed SQL 解析账号清单， 扫描 conftest 的所有登录用户名，任何一个不在 seed 内即变红； 另一条锁住推理前提（迁移里确实没有 operator 种子）。 两条都带「解析失败即失败」断言 —— 守卫自身静默失效是本项目反复踩过的坑。 3) idempotency_test.py（7 用例） 同键重放响应逐字节相同、同键重复提交只产生一条记录、body 字段幂等未回归、 不同键相互独立、同键作用域按 actor 隔离、5 线程并发同键业务恰好落库一次、 无键重复 Like 不得返回 500。 4) conftest.ApiClient.call 支持 headers 覆盖，供幂等用例携带自定义键。	2026-09-18 16:37:33 +08:00
WorkBuddy	7682abd85c	fix(api): give failures real HTTP semantics; fix 401/403 confusion and CORS default ... Phase 23B ended with an E2E assertion changed to expect "HTTP 200 + body.code == BAD_REQUEST", documented at the time as "this project's convention". That description was accurate about the code and wrong about the intent: it described a defect, and I made the test accommodate it instead of fixing it. Auditing it found the convention was already broken, not merely risky: - ~100 sites (105, across 30 controllers) do `return ApiResponse.error(...)` / `forbidden()` / `notFound()` with no exception and no `@ResponseStatus`, so the HTTP status is always 200. Gateways and APM cannot separate 4xx from 5xx; callers cannot tell "fix your request" (400) from "don't retry" (403) from "check state first" (409) from "retry later" (429). - miniapp/utils/api.js already had 401/403/429 branches that could never be reached, since the backend never returned those codes. The concrete damage: an expired token returned 403, so `onSessionExpired` never fired and users were stuck with no way back to the login flow. - SecurityConfig had no `authenticationEntryPoint`, so Spring's default `Http403ForbiddenEntryPoint` returned 403 for unauthenticated calls, with a framework body that has no `code` field at all. - CorsConfig defaulted `allowed-origins` to `*` together with `allowCredentials(true)`, while its comment claimed "localhost only by default". Comment contradicting code is worse than no comment: it reads as safe. - Only 4 files / 15 assertions in the whole backend suite touched HTTP status, which is how this survived. Approach: one definition, two applications, zero controller changes. - ApiResponseCode gains an `httpStatus` field — the single source of truth. The constructor requires it, so a new code cannot be added without one. - GlobalExceptionHandler reads status from the enum instead of hardcoding `@ResponseStatus` per handler. - New ApiResponseStatusAdvice (ResponseBodyAdvice) fills in the status just before the body is written, covering all ~100 direct-return sites without touching them. Two constraints, both noted in code: only downgrade when the current status is still 2xx (the advice also sees exception-handler results, and must not override an already-correct 401/403/409), and never alter the body. - SecurityConfig: entry point returns 401 with a uniform ApiResponse body; access denied handler returns 403 likewise. - CorsConfig: default changed to empty (deny). Both clients are same-origin anyway — nginx proxies /api/ and Vite proxies /api — so nothing depends on it. - miniapp api.js: 401/403/429/409 branches now prefer the server's `body.message`, otherwise "账号已被封禁" would be flattened to "无权限访问". Implementation trap worth remembering: `ServerHttpResponse` has `setStatusCode` but no getter, so reading the current status requires casting to `ServletServerHttpResponse`. Verification: 37 E2E passed (33 + 4 new contract cases), including a live-stack check that a controller's direct `notFound()` now yields 404 — that path throws no exception and never reaches the exception handler, so if the advice were inactive it would silently return 200 while the enum unit tests stayed green. Backend regression 662 / 0 failures / 0 errors / 3 skipped (+6 new guards). The first regression run had 3 failures, all tests asserting the old wrong behavior (anonymous access expected 403; outsiders reading a conversation expected 200). Fixed the assertions, not the implementation. Where 404 is used instead of 403 for "invisible", that is deliberate — it prevents probing whether another user's conversation exists — and the substantive assertions (e.g. that an unauthorized response must not leak message bodies) were kept. Not done, needs a product decision: third-party credential issuance, whether rate limiting is actually active, publishing OpenAPI externally, per-caller audit and quotas, pagination/idempotency coverage, desensitization boundaries.	2026-09-18 14:34:58 +08:00
WorkBuddy	730dddde30	test(e2e): Phase 23B — rebuild E2E infrastructure; fix 6 real prod defects it exposed ... Phase 23 closed as PARTIAL: fake coverage was gone, but the E2E layer itself was still empty — no conftest.py anywhere, ~15 fixtures that never existed, 6 files crashing at import on os.environ["E2E_PASSWORD"], and CI never ran E2E. STATUS's "10 E2E files / ~80+ cases ✅" described files that had never executed. Infrastructure delivered: - tests/e2e/conftest.py: ApiClient (trust_env=False — a host http_proxy turns localhost calls into 502), operator_token(username) / new_user / admin_token fixtures, and a session probe that calls pytest.exit(4) when the stack is unreachable. NOT skip: skip would launder "did not run" into "passed". - pytest.ini, tests/e2e/requirements.txt, and tests/e2e/sql/ seed_e2e_operators.sql — migrations contain NO operator seed at all, so a fresh database has zero logins; the seed creates 6 e2e accounts with role bindings, idempotent, password injected via `psql -v pwd`. - CI job `e2e`: compose up -> poll /health/live (timeout = fail) -> seed -> pytest -> always teardown. Gate D-23-D is now closed. - 8 E2E files migrated off import-time env reads; tautological assertions (`x == t or not x`), a counselor token standing in for content_editor, and a bare `status_code == 200` claiming to prove INV-020 were replaced with real permission/behavior assertions. Six real production defects found only by running against real PostgreSQL (H2 has zero coverage for all of them): - D-23B-A (Critical): stale V042__add_appointment_operator_register_permission.sql left in target/classes; src had replaced it with V042__add_service_location_ announcements.sql. Packing without clean put two V042 in the jar -> Flyway "Found more than one migration with version 042" -> app would not start. Guard added: testBuildOutputHasNoDuplicateMigrationVersions scans build output (src is clean, so only this catches it). - D-23B-B (High): non-UUID path variable reached the DB -> 500 + leaked `invalid input syntax for type uuid`. Now rejected at the controller. - D-23B-C (High): 6 E2E files raised KeyError at import -> never collected. - D-23B-E (Critical): permissions = 48, role_permissions for super_admin = 18, matchmaker = 0. V015's "grant all to super_admin" was a point-in-time snapshot; the 30 permissions added later were never granted. On a fresh stack an admin cannot create a service station and matchmakers can do nothing. V044 restores super_admin to its documented definition (not an expansion); the matchmaker permission set needs a product decision and is left as a residual. - D-23B-I (Medium): IllegalArgumentException (e.g. invalid activity type) was unmapped -> 500. Now BAD_REQUEST. - D-23B-J (High): `operator does not exist: uuid = character varying` — Java ids are String, columns are uuid, PostgreSQL does not implicitly cast in comparisons. Fixed at the source with JDBC `stringtype=unspecified` (docker profile); production datasource comes from deploy env and needs the same. One judgement retracted: an initial read suggested service_appointment.register was missing. It is not — the endpoint uses service.assisted_registration, seeded in V029, and the code deliberately avoids a duplicate permission. Nothing was changed on that basis. Verification: 33 E2E passed against a live stack; unreachable stack and a missing operator password both exit 4 (never skip/pass); backend regression 656 / 0 failures / 0 errors / 3 skipped (baseline 655, +1 guard, negatively validated by injecting a duplicate V042 -> exactly one test turned red).	2026-09-18 13:50:19 +08:00