RBAC是什么
RBAC是基于角色的访问控制（Role-Based Access Control ）在 RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。
RBAC一般都是公司内部进行使用，如财务部成员拥有查看财务报表的权限，人事部的成员拥有查看近期公司人员入职离职情况的权限等。
前台和后台
认证（是否登录）
权限（是否能查看到该资源）
频率（请求是否过于频繁）
而在后台中，也就是面向公司内部的人员拥有哪些权限。
就通过RBAC来进行管理。
普通员工（只有查看某一张表、某一条记录的权限）
小组长（能修改，能新增）
大BOSS（对任何表都具有增删改查的权限）
Django-Auth组件
最基本的权限管理其实三张表就够了，如下所示：
每个用户所属不同部门，那么不同部门拥有哪些权限则这些用户就具有哪些权限，这是非常广泛的。
但是三张表局限性太过强烈，比如Jerry不属于助教部，它也想获取辅导的权限该怎么做呢（管理人员也可以来进行辅导呀）？所以这个时候三表权限就显得捉襟见肘。
Django中所使用的是六表权限，（基本上五表权限就够了），它包含了用户与组的关系，用户与权限的关系（很重要），以及组与权限的关系。
那么有六张表时，就可以通过修改用户与权限关系表来让Jerry达到具有辅导的权限，但是Jerry并不会属于助教部，也就是额外的部门之外的权限。
这么说可能有点抽象，举一个更加形象的例子，如公司老板不属于任何部门，那么他理应来说应该具有该公司所有权限，所以三表不够用，至少要五表才OK。
混合的权限
在Django中，它只用了一张表，当然这也是可行的，我们来看一下admin中对超级管理员对于普通用户的管理
可以看见，Django会将前台和后台的用户统一存放至auth_user表中，同时用字段来区分到底是前台还是后台用户。
如果是后台用户，则才能够分配权限，当然Django提供的权限分配相对来说还是比较粗糙的，对于权限的区分甚至可以精确某一字段或记录。
这里不再过多阐述。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
