huang
c9fee7f2f6
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 5m42s
- 实现备注权限检查逻辑（authorization_service.go） - 添加备注权限验证存储层（authorization_store.go） - 新增集成测试覆盖备注权限场景 - 归档 fix-authorization-remark-permission 变更 - 同步 enterprise-card-authorization spec 规范
1.9 KiB
1.9 KiB
授权记录备注修改权限修复 - 设计
目标
- 代理用户无法修改非本人创建的授权记录备注。
- 企业用户无法修改任何授权记录备注。
- 平台/超级管理员可修改任意授权记录备注。
- 任何情况下都必须满足数据可见性（代理只能在自己店铺企业范围内操作）。
现状与风险点
- 备注更新当前仅按
id更新，缺少“创建者/可见性”约束。 - 现有数据权限 callback 主要作用于 Query，不覆盖 Update，因此必须在业务链路显式校验。
方案
1) Service 层统一鉴权
在 AuthorizationService.UpdateRecordRemark 内新增权限判断：
- 取当前用户信息（user_id/user_type/shop_id/enterprise_id）
- 先通过
GetByIDWithJoin获取授权记录详情（包含authorized_by、enterprise_id等） - 按规则判断：
- 平台/超级管理员：允许
- 代理：
- 必须
record.AuthorizedBy == 当前 user_id - 且授权记录对应企业必须属于当前店铺（
enterprise.owner_shop_id == shop_id，可通过 join 查询或使用现有原生 SQL 结果）
- 必须
- 企业：直接拒绝
2) Store 层更新增加约束（防御性）
提供一个“带约束”的更新方法（示例语义）：
- 平台路径：
UpdateRemarkByID(id, remark) - 代理路径：
UpdateRemarkByIDAndAuthorizedBy(id, remark, userID)（必要时再加 enterprise 范围约束）
确保即使上层遗漏判断，也难以越权更新成功。
3) 错误与返回
- 无权限：返回统一错误码（例如
CodeForbidden），错误信息使用中文并可被前端直接展示。
验收标准
- 平台用户可修改任意授权记录备注。
- 代理用户仅可修改自己创建的授权记录备注；修改他人创建的记录必须失败。
- 企业用户调用修改备注接口必须失败。
- 新增/更新用例后相关集成测试通过。