All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 5m39s
- 新增企业设备授权模块(Model、DTO、Service、Handler、Store) - 实现设备授权的创建、查询、更新、删除等完整业务逻辑 - 添加企业卡授权与设备授权的关联关系 - 新增 2 个数据库迁移脚本 - 同步 OpenSpec delta specs 到 main specs - 归档 add-enterprise-device-authorization 变更 - 更新 API 文档和路由配置 - 新增完整的集成测试和单元测试覆盖
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),错误信息使用中文并可被前端直接展示。
验收标准
- 平台用户可修改任意授权记录备注。
- 代理用户仅可修改自己创建的授权记录备注;修改他人创建的记录必须失败。
- 企业用户调用修改备注接口必须失败。
- 新增/更新用例后相关集成测试通过。