RBAC是什么

　　 RBAC是基于角色的访问控制（Role-Based Access Control ）在 RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。

　　 这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

　　 RBAC一般都是公司内部进行使用，如财务部成员拥有查看财务报表的权限，人事部的成员拥有查看近期公司人员入职离职情况的权限等。

前台和后台

　　 在前台中，也就是面向用户的资源中主要有三大权限，如下：

　　 认证（是否登录）

　　 权限（是否能查看到该资源）

　　 频率（请求是否过于频繁）

　　 而在后台中，也就是面向公司内部的人员拥有哪些权限。

　　 就通过RBAC来进行管理。

　　 普通员工（只有查看某一张表、某一条记录的权限）

　　 小组长（能修改，能新增）

　　 大BOSS（对任何表都具有增删改查的权限）

Django-Auth组件

　　 最基本的权限管理其实三张表就够了，如下所示：

　　 每个用户所属不同部门，那么不同部门拥有哪些权限则这些用户就具有哪些权限，这是非常广泛的。

　　 但是三张表局限性太过强烈，比如Jerry不属于助教部，它也想获取辅导的权限该怎么做呢（管理人员也可以来进行辅导呀）？所以这个时候三表权限就显得捉襟见肘。

　　 Django中所使用的是六表权限，（基本上五表权限就够了），它包含了用户与组的关系，用户与权限的关系（很重要），以及组与权限的关系。

　　 那么有六张表时，就可以通过修改用户与权限关系表来让Jerry达到具有辅导的权限，但是Jerry并不会属于助教部，也就是额外的部门之外的权限。

　　 这么说可能有点抽象，举一个更加形象的例子，如公司老板不属于任何部门，那么他理应来说应该具有该公司所有权限，所以三表不够用，至少要五表才OK。

混合的权限

　　 其实对于前台和后台用户来说，一般要分为两张表。

　　 比如前台的是该站用户，后台是该站管理人员。’

　　 在Django中，它只用了一张表，当然这也是可行的，我们来看一下admin中对超级管理员对于普通用户的管理

　　 可以看见，Django会将前台和后台的用户统一存放至auth_user表中，同时用字段来区分到底是前台还是后台用户。

　　 如果是后台用户，则才能够分配权限，当然Django提供的权限分配相对来说还是比较粗糙的，对于权限的区分甚至可以精确某一字段或记录。

　　 这里不再过多阐述。