不论是哪种后台管理系统,“人员权限”始终是绕不开的话题。无论是移动端,PC端产品,登陆都需要一个账号。只是对于C端的产品,大多都是用户自己注册即可。
而对于后台产品而言,是需要公司内部人员去创建账号的。每个使用系统的用户都有一个独一无二的账号,每个账号都有自己对应的权限。
多数情况下,除了超级管理员外,我们会对大多数的账号的权限做一些限制,以此来管理不同用户的使用权限问题。
譬如,做企业使用类软件,不同部门、不同职位的人的权限是不同的;再例如一款收费产品的收费用户和免费用户权限也是迥然不同的。
如果每个用户都单独做权限控制的话,当系统用户体量非常大的时候,就会发现以下问题:很多账号权限都是一样的,但每次都要再配一次;
当某类权限用户的权限需要修改时,无法批量修改,只能一个个去修改非常耗时;
这时候,聪明的产品先人就创建了“角色”的概念,通过对权限集的抽象,创立了角色,通过修改角色的权限,来控制拥有该角色的人员账号的权限。
其基本思想是,对系统操作的各种权限不是直接授予具体的用户,而是在用户集合与权限集合之间建立一个角色集合。每一种角色对应一组相应的权限。一旦用户被分配了适当的角色后,该用户就拥有此角色的所有操作权限。
这样做的好处是,不必在每次创建用户时都进行分配权限的操作,只要分配用户相应的角色即可,而且角色的权限变更比用户的权限变更要少得多,这样将简化用户的权限管理,减少系统的开销。
按照百度百科对RBAC的定义,我们可以理解为此模型是通过角色关联用户,角色关联权限的方式,间接赋予用户权限。
我们将角色单独创建一个二维表,将其不同的角色赋予不同的操作菜单的权限
再将不同的用户赋予不同的角色身份,从而得到相应的操作权限