KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

权限与多租户:从若依模型到注解式鉴权 — keel 龙骨

权限与多租户:从若依模型到注解式鉴权 的参考信息:权限与多租户:从若依模型到注解式鉴权

从这里开始:

课程导读

这门课针对一个具体阶段:系统开始有别人家的数据了——权限判定还散在各个接口的 if 里,多租户只是给每张表加了个 tenant_id,接口返回 403 时说不清是哪一层拦的,更糟的是某天发现有人看到了不该看的数据。权限是后端最容易写错、又最难被测出来的一层:错了不报错,只默默多给一点。这门课从国内最常见的若依式模型(菜单 + 按钮 + 接口 + 数据范围)出发,讲到多租户身份体系、RBAC 与 ACL 的分工、以及注解式声明鉴权的落地形态,全程用一套可运行的配套项目,并配五类越权用例做审计。

全景地图 → 若依式五表三层授权 → 数据权限塞进 SQL → 落地形态(函数/依赖/注解)
                                                          ↓
        多租户身份体系 → 隔离与泄密面 → RBAC 边界与 ACL → 缓存与一致性

八章的对应关系(前三章建模型,中间三章定形态,最后两章收边界):

章节 解决的核心问题
00 全景地图 认证、授权、数据隔离是三件事,别混成一个中间件
01 若依式权限手搓 五张表与三层授权,从零把模型跑通
02 数据权限 四种 scope,以及「把权限塞进 SQL」的两种做法
03 落地形态 函数内判定、依赖注入与注解各自的代价
04 多租户身份体系 user / member / tenant 三级 id 的分工与来源
05 隔离与泄密面 越权、403 与 404 的取舍,五类越权尝试怎么测
06 RBAC 的边界与 ACL 为什么「能改」不能是布尔值
07 缓存与一致性 权限改了多久生效,缓存键怎么设计才不会串租户

每章都有可观察结果、故障注入、自测题三段。这门课的证据全部来自可直接跑的越权用例:构造哪个身份、请求哪个接口、期望 403 还是 404,而不是"加个装饰器就行"。

配套课程:后端高并发工程拔高——那边保证系统不崩,这边保证数据不外泄;数据范围最终要落到 SQL 上,写法与执行计划接数据库与缓存调优。

进入 keel 阅读