背景
当前 ApikeyService 中,每个写操作方法(reset、updateRole、certify、updateQuota、changeStatus、createByParentCode 等)在方法体开头都显式调用 checkPermission(code, AkOperation.XXX),或直接调用 akPermissionChecker.check(db, operation)。
共约 10 处调用分散在业务方法内,权限校验与业务逻辑耦合,新增操作时存在遗漏校验的风险。
诉求
调研将权限校验抽取为 AOP 切面的可行性,并按结论实施重构:
- 定义注解(如
@RequireAkPermission(operation = AkOperation.RESET)),标注在 Service 或 Controller 方法上
- 切面拦截注解,统一完成"按 code 查 DB → 调 AkPermissionChecker.check"的流程
- 移除 Service 方法内的显式
checkPermission 调用
预期影响
- 权限校验逻辑集中在切面,Service 方法职责更单一
- 新增操作只需打注解,消除遗漏校验的风险
- 涉及
ApikeyService 中约 10 处调用点的改动,以及新增切面和注解定义
证据
N/A
相关链接
背景
当前
ApikeyService中,每个写操作方法(reset、updateRole、certify、updateQuota、changeStatus、createByParentCode 等)在方法体开头都显式调用checkPermission(code, AkOperation.XXX),或直接调用akPermissionChecker.check(db, operation)。共约 10 处调用分散在业务方法内,权限校验与业务逻辑耦合,新增操作时存在遗漏校验的风险。
诉求
调研将权限校验抽取为 AOP 切面的可行性,并按结论实施重构:
@RequireAkPermission(operation = AkOperation.RESET)),标注在 Service 或 Controller 方法上checkPermission调用预期影响
ApikeyService中约 10 处调用点的改动,以及新增切面和注解定义证据
N/A
相关链接