源码已上传至github，访问地址：console
招募合作者。 当前页面有点过时。 如果你愿意维护这个项目，并且有美术或者裁剪背景，请联系我(◕‿◕)
商业场景
权限管理网站会有定制化的业务需求。 不同的用户有不同的功能界面和不同的业务权限。 从项目角度来看，不同的用户有不同的角色，不同的角色绑定不同的功能模块，保证用户不能操作越权的功能。 基于这个出发点，可以考虑建立一个多用户、多角色、多种功能、灵活绑定用户角色菜单的程序。
此要求称为“基于角色的访问控制”，简称 RBAC。 RBAC 支持三个众所周知的安全原则：最小特权原则、职责分离原则和数据抽象原则。 在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员来从这些角色获得权限。 这大大简化了权限的管理。 在组织中，创建角色来完成各种任务，并根据用户的职责和资格为用户分配相应的角色。 可以轻松地将用户从一种角色分配到另一种角色。 可以根据新的需求和系统集成向角色授予新的权限，也可以根据需要从角色中回收权限。 可以建立人物与人物之间的关系来涵盖更广泛的客观环境。
为了实现从用户到功能的精确控制，数据库表结构设计和代码控制必须同时进行。 数据库表的设计包括用户表、用户角色表、菜单表、用户角色关联表、角色菜单关联表等表的字段和关系。 代码中需要使用的拦截器对访问的链接进行权限验证，根据用户动态加载界面，使用z-tree插件进行页面展示。
表结构设计
user：用户表，用于存储用户基本数据
role：角色表user存储角色名称
user-role：用户角色表，存储用户表id和角色表id。 一个用户id可能对应多个角色id。 如果使用的数据量较大，建议对两个id字段建立索引。
menu：菜单表用户存储所有功能菜单，包括菜单名称、链接、标签、父id、菜单级别等数据。 由于权限设置时需要显示菜单数据，因此必须将数据设计为输入结构，以方便加载和过滤
role-menu：角色菜单表user存储角色ID和菜单ID之间的关系。 同一角色ID可以对应多个菜单ID。 当数据量较大时，建议对两个ID字段建立索引。
开源效果展示（获取源码）
登录界面，简洁大方，干净整洁
权限管理员视角的功能菜单。 左侧导航栏包含三大块：用户管理、角色管理、菜单管理。 右侧是用户管理的列表数据。
权限管理员视角的角色管理菜单
权限管理员视角的角色授权
权限管理员视角的菜单管理
普通管理员视角的后台
实施说明
Easyui可用于后台界面。 界面效果如下。 为了演示，我去掉了授权功能。 实际上权限管理数据库表设计，还有用户、角色、菜单的授权功能。 用户登录时验证用户名和密码正确后，用户使用用户的ID去用户-角色表查找该用户拥有的所有角色以及该用户拥有的所有菜单。 当页面加载时，所有菜单都会使用 el 表达式进行解析并动态呈现。 出界面效果。
菜单在数据库中的存储方式如下：
menu_href 字段用于拦截器身份验证。 Button_htmlcontent字段是页面的标签，用于后台加载。 Button_htmlcontent的详细信息是：
`<a href="javascript:void(0)" onclick="jump("admin/store/getStoresByStoreState.do?storeState=1")">模块1`
后台授权模块分为三个二级模块：用户、角色、菜单。
用户模块包括添加、修改、查看用户。 添加新用户时，可以选择对应的角色：
角色模块包括角色的添加和修改。 角色对菜单的控制使用z-tree来以树的方式显示数据，通过检查绑定菜单。
菜单模块包含修改和查看菜单数据的操作。 左边的菜单数据也是一个z树。
拦截和身份验证
用户登录后，获取用户ID来查找角色和菜单，并按照标签格式显示在页面上。 权限认证需要使用拦截器。 每次获取操作的URL，如果用户有该菜单的权限，则可以正常进行操作。 否则，操作将会失败。
对于三级菜单的详细操作的认证，有两种解决方案。 第一种是按照与菜单相同的方式将每个三级菜单的所有操作的URL输入到数据库中，用户在操作时从数据库中查询并进行验证。 这样可以对用户添加、删除、修改、查看某个功能的权限进行详细的控制。 第二个选项是保持每个功能下的 url 命名和菜单 url 命名与上一段相同。 如果存在url为“admin/user/userList.do”的用户菜单，则该菜单下的新用户功能url为“admin/user/userAdd.do”。 如果您要操作添加新用户的功能，您必须拥有以“admin/user/”开头的三级菜单权限权限管理数据库表设计，否则操作将超出您的权限。
项目维护QQ群：
暂无评论内容