ThinkPHP的权限是基于用户组的。在本系统中RBAC Model(Role-based Access Model,基于角色的访问控制模型) 主要用到了5个数据表,分别是think_user (用户表)、think_role (用户角色表)、think_role_user (用户和用户角色的对应关系表)、think_node (操作节点表)、think_access (各个操作和用户角色的对应关系表)。
a) 用户表think_user,用来存放用户信息,其字段如表3.1所示。
表1 think_user表数据结构
|
字段名 |
字段类型 |
字段长度 |
默认值 |
备注 |
|
id |
smallint |
5 |
无 |
用户编号,主键 |
|
account |
varchar |
64 |
无 |
用户名,不为空 |
|
nickname |
varchar |
50 |
无 |
用户真实姓名,不为空 |
|
password |
char |
32 |
无 |
md5加密后的密码 |
|
last_login_time |
int |
11 |
0 |
最后登录时间 |
|
last_login_ip |
varchar |
40 |
NULL |
最后登录IP |
|
login_count |
mediumint |
8 |
0 |
登录次数 |
|
|
varchar |
50 |
NULL |
邮箱地址 |
|
class_id |
int |
11 |
NULL |
班级编号 |
|
create_time |
int |
11 |
无 |
创建时间 |
|
update_time |
int |
11 |
无 |
更新时间 |
|
status |
tinyint |
1 |
0 |
是否审核,不为空 |
注:password采用32位md5加密,class_id是用户所对应的班级编号。
b) 用户角色表think_role,用来存放角色信息,其字段如表2所示。
表2 think_role
|
字段名 |
字段类型 |
字段长度 |
默认值 |
备注 |
|
id |
smallint |
6 |
无 |
组的编号,主键 |
|
name |
varchar |
20 |
无 |
组的名称,不为空 |
|
remark |
varchar |
255 |
NULL |
用户角色描述 |
|
pid |
smallint |
6 |
NULL |
父路径编号 |
|
status |
tinyint |
1 |
0 |
是否审核,不为空 |
|
create_time |
int |
11 |
无 |
创建时间 |
|
update_time |
int |
11 |
无 |
更新时间 |
注:此表中可以插入父路径编号(pid)产生组的包含关系,对应的父路径编号(pid)为所属组的编号(id)。
c) 用户和用户角色的对应关系表think_role_user,其字段如表3所示。
表3 think_role_user
|
字段名 |
字段类型 |
字段长度 |
默认值 |
备注 |
|
role_id |
mediumint |
9 |
无 |
组的编号 |
|
user_id |
char |
32 |
无 |
用户编号 |
注:用户编号(user_id)对应哪一个role_id,则哪个用户就属于哪一个组,也可以让同一个用户对应多个组,这意味着,一个用户可以具有多个组的属性和操作权限。
d) 操作节点表think_node,用来存放操作对应的项目名称、模块名称以及操作名称,其字段如表4所示。
表4 think_node
|
字段名 |
字段类型 |
字段长度 |
默认值 |
备注 |
|
id |
smallint |
6 |
无 |
节点编号,主键 |
|
name |
varchar |
20 |
无 |
项目、模块的名字 |
|
title |
varchar |
50 |
NULL |
项目或模块的备注 |
|
sort |
smallint |
6 |
无 |
排序 |
|
type |
tinyint |
1 |
0 |
类型 |
|
level |
tinyint |
1 |
无 |
等级 |
|
pid |
smallint |
6 |
无 |
父路径编号 |
|
status |
tinyint |
1 |
0 |
是否审核,不为空 |
|
group_id |
tinyint |
3 |
0 |
分组 |
重点说一下think_node表,字段id是节点编号,用来产生关联关系,主键,自增方便索引;字段name就是项目,模块或者操作的名称了(严格区分大小写);字段pid 记录他们的从属关系,比如某一个模块是属于哪个项目,某个操作属于哪个模块;字段level 表示该节点的层级,只能为1、2、3分别代表项目、模块、操作动作,换句话就是说,level=1为项目,level=2为模块,level = 3就是操作了。比如admin项目,那么它的pid 是0(项目的pid都是0),level是1,name是admin了,假设admin项目下面有个user模块,那么它的level就应该是2,pid就是admin的id;再继续假设admin下面user模块的add操作,那么它的level就应该是3了,它的pid就是前面user对应的id。
e) 各个节点和用户角色的对应关系表think_access,其字段如表5所示。
表5 think_access
|
字段名 |
字段类型 |
字段长度 |
默认值 |
备注 |
|
role_id |
smallint |
6 |
无 |
用户组的编号 |
|
node_id |
smallint |
6 |
无 |
节点组的编号 |
|
level |
tinyint |
1 |
NULL |
节点表中的等级项 |
|
pid |
smallint |
6 |
NULL |
节点表中的父ID项 |
|
module |
varchar |
50 |
NULL |
节点表的可操作模块 |
注:如果用户组id和对应的节点id存放在这张表中,就表示该用户组的用户有权限进行对应节点的操作权限,level、pid分别表示该节点的层级和从属关系。
RBAC这些表模型之间的对应关系,如图1所示。
图1 RBAC表关系模型
posted on
浙公网安备 33010602011771号