前言
所谓权限,无非就是哪些用户允许干哪些事情,能够访问、操作哪些资源(web通常以url为粒度)。一般的后台管理(配置)系统都会做相应的权限控制(往往以用户-角色-资源为基础)。
用户-角色-资源(user-role-resource)
在实际业务中,某一类可以访问/操作的资源或者页面往往是对应某一类用户的。
例如:一个教务管理系统,小明同学、小红同学等用户可以进去查成绩,看课程安排;而张老师、王老师等用户则可以进去录入、修改学生成绩;资源表内容如下:
id | description | url |
---|---|---|
1 | 获取成绩 | /mark/get |
2 | 获取课程 | /course/get |
3 | 录入成绩 | /mark/add |
4 | 修改成绩 | /mark/modify |
学生这一类用户允许访问id为1和2的资源;
老师这一类用户允许访问id为3和4的资源;
我们将拥有共同访问资源的某一类用户,统称为某个角色(role)或某个用户组(group),用户属于某个角色,而这个角色会有属于它可以访问的资源。
如上面的小明同学属于学生这个角色,而学生这个角色有id为1、2的资源,即可以查成绩、获取课程等,但是没有老师这个角色的资源(录入和修改成绩等)。
当有一个新的同学(user)录入时,系统则可以直接将该user设定为学生这个角色,即可拥有其对应的所有权限。
数据库表设计
用户和角色为多对多关系:一个角色是对应有多个用户的(学生-->小明、小红);另外,一个用户可能会有多个角色,例如小杰是一个在读研究生(学生),但是也会给大一的同学讲课(老师);
角色和资源为多对多关系:一个角色是对应多个资源的(学生-->查看成绩、获取课程);另外,一个资源也是可以被多个角色访问的,例如修改个人信息,无论学生还是老师都可以拥有的。
具体表结构设计如下:
常规权限表结构
实际拦截操作
当用户登录之后,系统可以查询数据库,user-->role-->resource获取其可以访问/操作的资源。当该用户访问某个url时,例如/mark/modify ,web后台会设置一个专门的权限拦截器,比对判断该用户是否拥有该权限而做出相应处理。
其他拓展
- 不同的业务可能会有不同的设计,例如目前很多管理系统往往一个用户只会对应一个角色,这样也满足了实际需求;而这时候角色和用户就是1对多的情况了。
- 另外也存在这样的业务需求:用户除了其对应角色的权限外,还希望为该用户有其额外/特殊的对应的可访问资源,这时候user和resource之间会建立起来一个类似role_resource的多对多关系。
- 对于角色(role),有时候会有父级的设计(多一个parent_id字段等),这时候表示子级的角色可以访问父级的资源,属于一个权限拓展的过程。比如美国大片中小士兵的id为1,而比他高一级的排长的parent_id则为1,这时候排长起码会有小士兵的权限;再上一级,连长的parent_id则是排长的id,一级一级下去。
- 还有一些的资源会细分到以某个函数为粒度的,这时候表设计仍然类似,具体拦截方法不一样而已。
虽然拓展性有很多,但是不建议将权限关系弄得过于复杂,满足自身业务需求即可。
网友评论