源码已上传到github,访问地址:console
招募合作者,现在的页面有些古板,有意愿维护这个项目且有美工或切图底子的coder请联系我哈(◕‿◕)
业务场景
权限管理类的网站会存在一个定制化的业务需求,不同的用户拥有不同的功能界面、不同的业务权限.从项目角度来描述就是不同的用户拥有不同的角色,不同的角色绑定了不同的功能模块,并且要保证用户不能操作权限之外的功能。基于这样的出发点可以考虑建立一套多用户、多角色、多种功能、用户<–>角色<–>菜单灵活绑定的程序。
这种需求名为‘基于角色的权限访问控制’(Role-Based Access Control),简称为RBAC。RBAC支持三个著名的安全原则:最小权限原则,责任分离原则和数据抽象原则。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。
想要做到从用户到功能的精确控制,要从数据库表结构设计和代码控制同时进行。数据库表的设计包含用户表、用户角色表、菜单表、用户角色关联表、角色菜单关联表等表的字段及关联关系。代码中需要使用的拦截器对访问的链接进行权限验证、根据用户动态加载界面、页面展示需要使用z-tree插件。
表结构设计
user:用户表用于存放用户基础数据
role:角色表用户存放角色名称
user-role:用户角色表,存放用户表id河角色表id,一个用户id可能会对应多个角色id,如果使用数据量很大,建议对两个id字段做索引
menu:菜单表用户存放所有功能菜单,包含菜单名称、链接、标签、父级id、菜单等级等数据,因为菜单数据要在权限设定时做展示,所以数据要设计为输结构,方便加载和筛选
role-menu:角色菜单表用户存放角色id和菜单id的关联关系,同样一个角色id可能会对应多个菜单id,数据量大的情况下建议对两个id字段做索引
开源效果展示(获取源码)
登录界面,简单大方,干净整洁
权限管理员视角下的功能菜单,左侧导航栏包含用户管理、角色管理、菜单管理三个大块,右侧为用户管理的列表数据
权限管理员视角下的角色管理菜单
权限管理员视角下的角色授权
权限管理员视角下的菜单管理
普通理员视角下的后台
实现说明
后台界面可以使用easyui,界面效果如下,为了演示我去掉了授权功能,实际情况还有一个用户、角色、菜单的授权功能。用户在登录时验证了用户名和密码准确无误后,通过用户的id去user-role表查到用户拥有的所有角色并找到用户拥有的所有菜单,页面加载时使用el表达式解析所有菜单,动态呈现出界面效果。
菜单在数据库存储如下:
menu_href字段用作拦截器鉴权,button_htmlcontent字段是页面的标签用作后台加载,button_htmlcontent详细内容为:
`<a href="javascript:void(0)" onclick="jump("<%=rootPath%>admin/store/getStoresByStoreState.do?storeState=1")">模块1</a>`
后台的授权模块分为用户、角色、菜单三个二级模块
用户模块包含用户的增、改、查,新增用户时可以选择对应的角色:
角色模块中包含了角色的新增和修改,其中角色对菜单的控制要使用z-tree对数据的树状展示,通过勾选绑定菜单
菜单模块中包含了对菜单数据的修改、查看的操作,左侧的菜单数据也是一颗z-tree树,
拦截与鉴权
用户登录后相应的获取用户id找到角色和菜单,并且按照标签的格式在页面展示出来。权限鉴定要使用到拦截器,每次获取操作的url,如果用户有此菜单的权限即可正常操作,反之提醒操作失败。
对于三级菜单上详细操作的鉴权有两种方案,第一种是将每个三级菜单上所有操作的url都和菜单一样录入数据库,用户在操作的时候从数据库查询并鉴权。这么做可以详细的控制到用户对某个功能的增、删、改、查权限。第二种方案是每个功能的下的url命名和菜单url命名保持前段相同,假如存在某个用户菜单的url为"admin/user/userList.do",这个菜单下的新增用户功能url为"admin/user/userAdd.do"。想要操作新增用户的功能,必须有"admin/user/"开头的三级菜单权限,否则操作越权。
项目维护QQ群: