MySQL 系统学习 第五阶段：企业级 MySQL 实战开发 第二章：RBAC 权限系统设计

一、什么是 RBACRBAC 全称Role-Based Access Control基于角色的访问控制它的思想非常简单不给用户直接分配权限而是先给用户分配角色再给角色分配权限。例如张三 │ ▼ 管理员 │ ▼ 拥有所有权限或者李四 │ ▼ 普通员工 │ ▼ 查看订单 查看商品 不能删除数据二、为什么不用直接给用户分配权限假设公司有1000 名员工50 种权限如果直接分配张三 ├── 查看用户 ├── 删除用户 ├── 添加商品 ├── 删除商品 ├── 查看订单 ...1000 人都要单独维护权限。维护成本非常高。使用 RBAC管理员 ├── 查看用户 ├── 删除用户 ├── 添加商品 ├── 删除商品 运营 ├── 查看商品 ├── 修改商品 客服 ├── 查看订单 ├── 修改订单用户只需要绑定角色张三 ↓ 管理员如果管理员权限变化只修改一次管理员角色所有管理员立即生效。三、RBAC 的四个核心对象整个 RBAC 可以抽象成四张核心表User用户 Role角色 Permission权限 Menu菜单可选企业中最常见的是User ↓ Role ↓ Permission四、用户User用户就是登录系统的人。例如idusername1admin2tom3jack对应 SQLCREATE TABLE user( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50), password VARCHAR(255) );这里只保存登录账号密码手机号邮箱不要保存权限。五、角色Role角色代表一类人的身份。例如id角色1超级管理员2管理员3运营4客服5访客SQLCREATE TABLE role( id BIGINT PRIMARY KEY AUTO_INCREMENT, role_name VARCHAR(50), role_code VARCHAR(50) );例如role_code ADMIN USER OPERATOR程序一般判断role_code而不是role_name因为名称可以修改管理员 ↓ 系统管理员code一般不会变。六、权限Permission权限表示系统允许做什么。例如查看用户 新增用户 删除用户 修改用户 查看订单 删除订单SQLCREATE TABLE permission( id BIGINT PRIMARY KEY AUTO_INCREMENT, permission_name VARCHAR(100), permission_code VARCHAR(100) );例如permission_code user:list user:add user:delete order:list order:delete以后NestJSGuard就是判断permission_code七、为什么需要角色中间层很多新人会问为什么不能用户 ↓ 权限原因如果1000人。每个人50权限。需要50000条关系。修改非常困难。而用户 ↓ 角色 ↓ 权限权限只维护角色。维护成本极低。八、表之间关系现在开始画关系。一个用户可以有多个角色。例如Tom ↓ 管理员 ↓ 运营所以User和Role是多对多角色和权限也是多对多例如管理员拥有用户管理 商品管理 订单管理运营拥有商品管理 订单查看所以RolePermission也是多对多。九、为什么多对多不能直接存例如错误设计Userid username roleroleADMIN,USER问题SQL无法JOIN。无法建立外键。无法索引。违反第一范式1NF。所以需要中间表。十、User 与 Role多对多需要user_roleCREATE TABLE user_role( user_id BIGINT, role_id BIGINT );例如user_idrole_id111223表示用户1 ↓ 管理员 ↓ 运营十一、Role 与 Permission多对多同样建立CREATE TABLE role_permission( role_id BIGINT, permission_id BIGINT );例如role_idpermission_id111213十二、最终数据库结构最终RBAC数据库User │ │ │ User_Role │ │ Role │ │ Role_Permission │ │ Permission或者画得更完整一点--------- ------------- -------- | User |------- | User_Role |------- | Role | --------- ------------- -------- | | v ------------------ | Role_Permission | ------------------ | | v -------------- | Permission | --------------十三、企业后台权限流程用户登录输入账号密码↓查询user↓查询user_role↓查询role_permission↓得到permission↓生成JWT。以后每次请求判断permission_code例如user:add有允许。没有403。十四、本章总结表作用user用户role角色permission权限user_role用户角色关系role_permission角色权限关系核心关系User ↓ Role ↓ Permission都是通过中间表建立多对多关系。 本章核心一句话RBAC 的核心思想是用户拥有角色角色拥有权限通过角色作为中间层实现权限的统一管理和灵活扩展。本章思考题为什么 RBAC 不直接把权限分配给用户而要增加 Role角色这一层因为角色是权限的集合增加角色这一层可以实现权限的统一管理降低维护成本。为什么 User 和 Role、Role 和 Permission 都设计成多对多关系用户可以有多个角色角色可以有多个权限因此两者都需要设计成多对多关系。为什么多对多关系需要中间表而不能把多个角色直接存到一个字段中中间表符合数据库范式支持外键、索引和高效查询是实现多对多关系的标准方式。role_name和role_code有什么区别为什么程序更适合使用role_coderole_name 用于展示role_code 用于程序判断因为 code 稳定不会因业务名称变化而影响代码。如果一个用户同时拥有两个角色而两个角色都包含同一个权限最终这个用户应该拥有几次这个权限为什么多个角色的权限最终会取并集并自动去重同一个权限只会生效一次。