在本号之前的文章中,已经为大家介绍了很多关于spring security的使用方法,也介绍了rbac的基于角色权限控制模型。但是很多朋友虽然已经理解了rbac控制模型,但是仍有很多的问题阻碍他们进一步开发。比如:
那么本文就希望将这些问题,与大家进行一下分享。
上图中:
本文讲解只将权限控制到菜单的访问级别,即控制页面的访问权限。如果想控制到页面中按钮级别的访问,可以参考menu与rolemenu的模式同样的实现方式。或者干脆在menu表里面加上一个字段区别该条记录是菜单项还是按钮。
为了有理有据,我们参考一个比较优秀的开源项目:若依后台管理系统。
之所以先将部门管理提出来讲一下,是因为部门管理没有在我们上面的rbac权限模型中进行提现。但是部门这样一个实体仍然是,后端管理系统的一个重要组成部分。通常有如下的需求:
以下sql以mysql为例:
create table `sys_org` ( `id` int(11) not null auto_increment, `org_pid` int(11) not null comment '上级组织编码', `org_pids` varchar(64) not null comment '所有的父节点id', `is_leaf` tinyint(4) not null comment '0:不是叶子节点,1:是叶子节点', `org_name` varchar(32) not null comment '组织名', `address` varchar(64) null default null comment '地址', `phone` varchar(13) null default null comment '电话', `email` varchar(32) null default null comment '邮件', `sort` tinyint(4) null default null comment '排序', `level` tinyint(4) not null comment '组织层级', `status` tinyint(4) not null comment '0:启用,1:禁用', primary key (`id`) ) comment='系统组织结构表' collate='utf8_general_ci' engine=innodb ;
注意:mysql没有oracle中的start with connect by的树形数据汇总sql。所以通常需要为了方便管理组织之间的上下级树形关系,需要加上一些特殊字段,如:org_pids:该组织所有上级组织id逗号分隔,即包括上级的上级;is_leaf是否是叶子结点;level组织所属的层级(1,2,3)。
create table `sys_menu` ( `id` int(11) not null auto_increment, `menu_pid` int(11) not null comment '父菜单id', `menu_pids` varchar(64) not null comment '当前菜单所有父菜单', `is_leaf` tinyint(4) not null comment '0:不是叶子节点,1:是叶子节点', `name` varchar(16) not null comment '菜单名称', `url` varchar(64) not null comment '跳转url', `icon` varchar(45) null default null, `icon_color` varchar(16) null default null, `sort` tinyint(4) null default null comment '排序', `level` tinyint(4) not null comment '菜单层级', `status` tinyint(4) not null comment '0:启用,1:禁用', primary key (`id`) ) comment='系统菜单表' collate='utf8_general_ci' engine=innodb ;
上图为角色修改及分配权限的页面
create table `sys_role` ( `id` int(11) not null auto_increment, `role_id` varchar(16) not null comment '角色id', `role_name` varchar(16) not null comment '角色名', `role_flag` varchar(64) null default null comment '角色标识', `sort` int(11) null default null comment '排序', primary key (`id`) ) comment='系统角色表' collate='utf8_general_ci' engine=innodb ;
create table `sys_role_menu` ( `id` int(11) not null auto_increment, `role_id` varchar(16) not null comment '角色id', `menu_id` int(11) not null comment '菜单id', primary key (`id`) ) comment='角色菜单多对多关联表' collate='utf8_general_ci' engine=innodb ;
create table `sys_user` ( `id` int(11) not null auto_increment, `org_id` int(11) not null, `username` varchar(64) null default null comment '用户名', `password` varchar(64) null default null comment '密码', `enabled` int(11) null default '1' comment '用户账户是否可用', `locked` int(11) null default '0' comment '用户账户是否被锁定', `lockrelease_time` timestamp null '用户账户锁定到期时间', `expired_time` timestamp null '用户账户过期时间', `create_time` timestamp null default current_timestamp on update current_timestamp comment '用户账户创建时间', primary key (`id`) ) comment='用户信息表' engine=innodb ;
create table `sys_user_role` ( `id` int(11) not null auto_increment, `role_id` varchar(16) null default null, `user_id` varchar(18) null default null, primary key (`id`) ) collate='utf8_general_ci' engine=innodb ;
在用户的信息表中,体现了一些隐藏的需求。如:多次登录锁定与锁定到期时间的关系。账号有效期的设定规则等。
当然用户表中,根据业务的不同还可能加更多的信息,比如:用户头像等等。但是通常在比较大型的业务系统开发中,业务模块中使用的用户表和在权限管理模块使用的用户表通常不是一个,而是根据某些唯一字段弱关联,分开存放。这样做的好处在于:经常发生变化的业务需求,不会去影响不经常变化的权限模型。
如对本文有疑问, 点击进行留言回复!!
关于启动appium-desktop,报错:Cannot extract apk info using apkanalyzer. Falling back to aapt. Original ....
Gradle 发布共享库——如何通过Gradle发布Android依赖库(aar)到 jitpack 公共仓库
Gradle 发布共享库——如何通过Gradle发布java依赖库(jar)到 jitpack 公共仓库(—)
【杭电多校2020】第二场1001.Total Eclipse(并查集)
java.lang.IllegalStateException: Only fullscreen opaque activities can request orientation问题解决
网友评论