版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/leo187/article/details/79645726
业务场景
- 权限管理类的网站会存在一个定制化的业务需求，不同的用户拥有不同的功能界面、不同的业务权限.从项目角度来描述就是不同的用户拥有不同的角色，不同的角色绑定了不同的功能模块，并且要保证用户不能操作权限之外的功能。基于这样的出发点可以考虑建立一套多用户、多角色、多种功能、用户<–>角色<–>菜单灵活绑定的程序。
- 这种需求名为‘基于角色的权限访问控制’（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/"开头的三级菜单权限，否则操作越权。