WorkBuddy
cbb4f64fdc
Continues the HTTP-semantics work. Fixing 401/403 exposed a worse defect on the
same axis: who is allowed to reach which endpoint.
Root cause chain:
- PlatformPrincipal has two implementations (OperatorPrincipal / UserPrincipal),
chosen by JwtAuthFilter from the token type.
- `@AuthenticationPrincipal UserPrincipal` against an OperatorPrincipal is a type
mismatch, and Spring Security returns null (errorOnInvalidType defaults to
false) instead of failing.
- 244 uses of that annotation repo-wide; only 48 null-check. The rest NPE -> 500
when reached with an operator identity.
- The fallback rule was `.authenticated()`, which an operator token satisfies, so
such requests did reach user-facing controllers.
Adding ~196 null checks would be mechanical, easy to miss, and does nothing to
constrain future code. The mismatch is between identity type and endpoint, so it
is fixed once, at the authentication layer: the fallback becomes
`.hasRole("USER")` (operator -> ROLE_OPERATOR, user -> ROLE_USER, per JwtAuthFilter).
Operator requests to user endpoints now get 403 before any controller runs.
Trap worth recording: operator endpoints are not all under /operator/ —
/counseling/services/operator/queue, /content/operator/articles,
/activities/operator/checkin/scan, /service-appointments/operator/list and others
sit deeper inside business paths. The first attempt covered them with
`requestMatchers("/**/operator/**")`, which fails at runtime:
PatternParseException: No more pattern data allowed after {*...} or ** pattern element
Spring's PathPattern permits `**` only as the final element. Worse, the symptom is
a 500 from the whole filter chain (Tomcat HTML error page, not our JSON), and E2E
went from 37 passed to 33 failed — an error far removed from its cause. Now the
nine prefixes are listed explicitly, each ending in /**.
Because explicit enumeration can be forgotten as endpoints are added, and because
the failure mode is "operators locked out of their own admin module" (invisible to
user-side tests), SecurityPathCoverageTest parses the OPERATOR rule prefixes out of
SecurityConfig source, walks every *Controller.java, joins class-level and
method-level mapping paths, and asserts every path containing /operator/ is
covered (/auth/operator/** excluded by design). Two things that would silently
neuter it, both handled: it must parse only the .hasRole("OPERATOR") chain — pulling
in the permitAll or fallback rules would mark everything covered — and the test
working directory is the repo root, not the Maven module root.
Verification: negatively validated by removing /content/operator/** -> exactly one
test turns red listing the six affected ContentController endpoints; restored.
E2E 40 passed (37 + 3 identity-isolation cases). Backend regression 664 / 0
failures / 0 errors / 3 skipped.
测试基础设施
测试目录结构
tests/
├── invariants/ # 核心不变量测试（每次CI必跑）
│ ├── INV-001_Required不可自动放宽.test.ts
│ ├── INV-002_未Mutual不可聊天.test.ts
│ ├── INV-003_Block后双方不可互动.test.ts
│ ├── INV-004_双向并发Like只创建一个Match.test.ts
│ ├── INV-005_Activity最后一个名额不可超卖.test.ts
│ ├── INV-006_单向活动意向不可泄露.test.ts
│ ├── INV-007_红娘不能替用户Like.test.ts
│ ├── INV-008_非授权Operator不能读取身份证.test.ts
│ ├── INV-009_非案件上下文不能读取聊天.test.ts
│ └── INV-010_跨Organization不能越权.test.ts
├── unit/ # 单元测试
├── integration/ # 集成测试
├── api/ # API 测试
├── permission/ # 权限测试
├── concurrency/ # 并发测试
└── e2e/ # 端到端测试
Phase 01 测试骨架
每个测试文件至少包含：
- 测试描述
- 前置条件
- 操作步骤
- 预期结果
- 断言
运行测试
# Backend 单元测试
cd backend
./mvnw test
# Backend 集成测试
./mvnw verify
# Admin Web 构建检查
cd admin-web
pnpm build
# Miniapp 编译检查
cd miniapp
npx tsc --noEmit