|
|
@@ -2678,4 +2678,5 @@ cd /sc-data/cfc && git diff --name-only HEAD~14 HEAD | grep -E "chat\.vue|schema
|
|
|
19. 改 6 个方法签名会破坏**两个**测试文件:除修订 14 已列的 `GuideFamilyTaskControllerTest`(15 处调用)外,还有 `GuideRolePermissionTest`(4 处调用),修订 14 仍遗漏 → 两个文件都需补 `@MockBean GuideFamilyAccessGuard`(Mockito 默认返回 `null` 等价放行,既有用例断言不受影响)。
|
|
|
20. 任务 4 测试辅助方法 `planWithStatus` 固定 `setId(5L)`,而 `getPlanForFamily_匹配返回方案` 用 `selectById(99L)` 打桩却断言 `getId()==99` → 必然失败(实测 `expected: <99> but was: <5>`)→ 该用例需显式 `plan.setId(99L)` 后再打桩。注意同一辅助方法在 `不属于该家庭返回null` 用例中无害(只断言 null)。
|
|
|
21. 任务 5 步骤 3 预期「`cannot find symbol: class PlanApproveResultDTO`」**不可能发生**——步骤 1 已创建该 DTO。真实 RED 是 `incompatible types: com.etotem.cfc.entity.HealthPlan cannot be converted to com.etotem.cfc.dto.PlanApproveResultDTO`(因 `approveAndPublish` 仍返回 `HealthPlan`)。
|
|
|
-22. 任务 5 步骤 5 的安全性依据「`approvePlan` 无任何页面引用」**不准确**:`cfc-frontend/pages/health/health-plan-summary.vue:272` 确有 `import { ... approvePlan }`。但全仓检索 `approvePlan(` **无任何调用点**(死导入),故改返回类型确实不破坏前端。正确依据是「无调用」而非「无引用」。
|
|
|
+22. 任务 5 步骤 5 的安全性依据「`approvePlan` 无任何页面引用」**不准确**:`cfc-frontend/pages/health/health-plan-summary.vue:272` 确有 `import { ... approvePlan }`。但全仓检索 `approvePlan(` **无任何调用点**(死导入),故改返回类型确实不破坏前端。正确依据是「无调用」而非「无引用」。
|
|
|
+23. 任务 6 `resolvePlan` 的注释「用反查出的真实 familyId 再校验一次,防止路径与库内不一致绕过」**事实错误**:`getPlanForFamily(planId, familyId)` 本身已按 familyId 过滤,`plan.getFamilyId()` 必然等于上一行已通过 `checkFamilyAccess` 校验的 `familyId`,因此 recheck **永不拒绝任何请求**。真正的 IDOR 防线是第一道 `checkFamilyAccess` + `getPlanForFamily` 返回 null 即 403。recheck 调用予以保留(纵深防御、零成本),但注释必须改为「兜底重复校验,勿依赖它拦截路径不一致」,防止后人误判此处存在真实防护而在其他端点放弃校验。
|