本文以最简单逻辑解释什么是rbac模式
本文全是个人理解，如有不恰当的地方，请指出，互相学习

RBAC（Role-Based Access Control）权限模型的概念，即：基于角色的权限控制。通过角色关联用户，角色关联权限的方式间接赋予用户权限。

1.创建最基本的三个表，即 人员表(admin)，角色表(role)，功能表(func),和一个扩展人员权限表（admin_func）

• 人员表：必有得字段（role_id）
• 角色表：必有的字段（func_ids）
• 人员扩展权限表：必有得字段（admin_id,func_ids）

2.整体思路

• 用户登录，查人员表数据，获取到角色唯一标志（这里是id）
• 通过角色唯一标记，获取权限（这里角色里面的func_ids里面的数据通常是逗号隔开的字符串，我们在业务逻辑上处理时，转换成数组比较好处理）
• 用户操作任意一个功能，获取到该功能的 控制器 和 方法 去功能表里查获取到id
• 获取到的id判断是不是在上一步查的角色所对应的func_ids里面

3.特殊情况

• 如果在一个公司内，举个例子，在同一个公司有两个销售部（a部门，b部门），两个销售部的领导都是有一样的权限的（角色是一样的），这个时候，公司高层决定,a部门的领导为总领导，可以查看b部门的数据，这个时候，都知道，a和b的部门领导角色不能修改，一种笨方法，在开一个账号，分配角色和权限，可以查看b部门的数据，这样不符合工作逻辑，对领导不友好，下面就有了扩展人员权限
• 在扩展人员表里绑定人员id和对应的功能表的id
• 这样在我们操作的时候就多了一个步骤，多查一个表（admin_func），获取到的数据在和角色里面的权限进行合并，在做后面业务逻辑操作

4.在什么位置实现权限

• 在你看来怎么方便怎么实现，最好的就在中间件里实现权限验证，可以有效的降低无效访问

中间件的主要应用场景可以包括对HTTP请求的数据过滤、权限检测、请求拦截等行为，使用中间件能够让控制器的定义更加简单，很多额外的非核心业务流程的处理都可以交给中间件执行。