Source: https://blog.csdn.net/u010004317/article/details/53996757
preface
I have been working as a permission developer for a while recently. From design to coding, I have participated in the whole process, and have an essential understanding of permission development. As one of the most basic and most important functions of a system, permission management is A system is very important. Today, I will talk about the mountains, talk about some things developed by my system's permissions, and communicate with you.
1. The original permission management mode of the system
In the past, the permission management of this system was handled through configuration files. The general process is like this. Users are divided into multiple user groups, and then each user group corresponds to the id of multiple users. Every time the page is accessed, it will read Take the information of this configuration file, determine which user group the logged-in user id belongs to, and then determine on the page whether this user group has permission to access the link. The format of the configuration file is this: {"adm" : [1,2,34], "dev" : [5,6,1]} what problems does this bring? There are the following:
- Permission management is confusing, a user id may be in multiple permission groups
- Every time you update the configuration file, you have to go online again, trouble
- Without a graphical interface, it is difficult to configure permissions
- The page has too many if judgment statements, resulting in poor code readability
2. New permission management development
It should be emphasized here that this system number does not use the popular framework outside, but is used by jsp plus the previously encapsulated framework, so you can find that my permission development is not used in the previous framework development permission. Filters, listeners and the like, or you might say, filters and listeners can be used without a framework, because this is a Servlet thing. Here I want to explain, I personally think that the permissions management on the market can be roughly divided into two types:
-
When the user enters the system, it does not judge the authority, and develops all the function entries in the system to the user. Every time the user clicks on the corresponding function entry, it is judged by the link and the user whether the user has the authority to use the function. , if you don't have permission, you will jump to the prompt page without permission. This function is usually done by using filters.
-
When the user enters the system, the user's authority is judged, and the corresponding function entry is developed according to the user's authority. Users with different authority see different pages. Compared with the first one, the advantage of this kind is that it can block the function entry that the user does not have permission to access. The user can only see the function entry possessed by his own authority, but he does not know what other functions the system has, and more good for confidentiality. However, if you only judge the permissions when the user enters the system, and don't judge again later, then there will be a problem that does not occur in the first case, that is, permission testing. I can simulate the address bar. Change the parameters (some submission methods have to be submitted by get, so the address bar will inevitably contain parameters) to achieve the purpose of destroying permissions. If the code is not written rigorously, this problem will occur on your system. The better way is, Every time the page is accessed, the permissions are re-judged. So the place where you don't need to use the filter has to be used again.
However, because of the particularity of the system, the system's permission development will not use filters and listeners. All permission judgments are written on a public page, and then included on each page. It achieves an effect similar to a filter. However, I don’t agree with this way of writing. Frameworks and filters can exist, and naturally they have their reasons. I have also done development with framework permissions before, and I think that is more convenient, of course. , this is off topic.
(1) Database design
In other words, I still encountered a lot of obstacles when designing the database at the beginning, because I still had the remaining power of the original authority management of the system in my mind, and it was affected a little by it during the initial design. Later, I simply did not refer to the previous ones. Rights management mode, make your own set out.
User table (acctUser)
| field | Types of | describe |
|---|---|---|
| id | int(11) | User unique ID, primary key |
| acct | varchar(20) | account |
| name | varchar(20) | Name |
| createTime | int(11) | User creation time, timestamp |
| lastLoginTime | int(11) | User's last login time, timestamp |
| the | int(1) | Whether to delete, logical deletion, 1 for deletion, 0 for non-deletion |
| mobile | varchar(20) | User mobile phone |
| enail | varchar(50) | User mailbox |
| remark | varchar(200) | User comments |
Role table (acctRole)
| field | Types of | describe |
|---|---|---|
| roelId | int(11) | Role unique identifier, primary key |
| roleName | varchar(30) | character name |
| roleDescribe | varchar(30) | role description |
Permissions table
In this system, the permissions will be refined into three kinds of permissions, the first is the permission of the navigation bar, the second is the permission of the sidebar, and the last is the button and business permission of the page, as shown in the following figure
Navigation bar permission table (acctHeaderMenuPermission)
| field | Types of | describe |
|---|---|---|
| headerMenuId | int(11) | Navigation bar permission unique identifier, primary key |
| headerMenuName | varchar(30) | Navigation bar permission menu name |
| headerMenuUrl | varchar(255) | Navigation Bar Permissions Menu URL |
| menuOrder | tinyint(3) | The order of the navigation bar permission menu, which is sorted according to this field when displayed |
Sidebar permission table (acctSideMenuPermission)
| field | Types of | describe |
|---|---|---|
| sideMenuId | int(11) | Sidebar permission unique identifier, primary key |
| sideMenuName | varchar(30) | Sidebar permission menu name |
| sideMenuUrl | varchar(255) | Sidebar Permissions Menu URL |
| headerMenuId | int(11) | The navigation bar permission menu Id corresponding to the sidebar permission menu, foreign key |
| menuOrder | tinyint(3) | The order of the side permission menu, which is sorted according to this field when displayed |
Business or operation permission table (acctDetailMenuPermission)
| field | Types of | describe |
|---|---|---|
| menuId | int(11) | Permission unique identifier, primary key |
| menuName | varchar(30) | permission menu name |
| sideMenuId | int(11) | Sidebar permission menu ID corresponding to page business or operation permission, foreign key |
| bizOrOperate | tinyint(3) | The business or operation corresponding to the permission |
User role table (acctUserRole)
| field | Types of | describe |
|---|---|---|
| acctId | int(11) | UserId, foreign key, primary key |
| roleId | int(11) | role id, foreign key, primary key |
Role - Navigation Bar Permission Table (headerMenuRole)
| field | Types of | describe |
|---|---|---|
| menuId | int(11) | Permission Id, Primary Key, Foreign Key |
| roleId | int(11) | role id, primary key, foreign key |
Role - Sidebar Permission Table (sideMenuRole)
| field | Types of | describe |
|---|---|---|
| menuId | int(11) | Permission Id, Primary Key, Foreign Key |
| roleId | int(11) | role id, primary key, foreign key |
Role - Business or Operation Permission Table (detailMenuRole)
| field | Types of | describe |
|---|---|---|
| menuId | int(11) | Permission Id, Primary Key, Foreign Key |
| roleId | int(11) | role id, primary key, foreign key |
Database Model Diagram
(2) Page design
Page design is also an embarrassing thing. I found a lot of pictures of permission allocation on the Internet, and found that many of them did not conform to my existing system. Implement the assignment of permissions and roles
Privilege management initialization page
The system has three levels of permissions, namely navigation bar permissions, sidebar permissions and business/operation permissions, which form a parent-child relationship, which just corresponds to the parent and child nodes of the tree, and there are add, edit and delete buttons behind each node.
Increase permissions
点击“添加权限”的按钮，就会有弹窗让用户添加相应的权限，每次添加权限都要选择该权限所对应的父节点，权限名，权限URL和权限展示顺序。可能有读者对于权限URL不是很了解，我在这里解释一下，因为系统本身的原因，每个权限其实就是对应着页面的每个菜单，每个菜单肯定都有自己的URL，如果某个用户有这个菜单的权限，自然就有了访问这个URL的资格
编辑权限
编辑权限和添加权限是差不多的，这里就不再赘述
删除权限
删除权限，因为权限之间是有父子关系的，在数据库中表现为主外键关系，数据库的外键关系为级联，也就是说如果父权限被删除了，与它对应的所有子权限也将被删除。其实这个外键对应关系我刚开始是限制在有子权限的情况下不能删除父权限的，后来经过考虑，综合了自己和系统本身的很多因素,还是把外键关系设置为级联的了。但是级联删除有个坏处，如果在删除子节点成功后，删除父节点失败了，那么就会出现删除不完全的情况，可能会出现不可预知的错误，因此，在做删除操作的时候，我都会开启一个事务，如果删除失败我就回滚，删除成功才提交事务，遵循数据库的ACID
角色管理初始化页面
角色管理和用户管理其实大同小异，所以就只讲角色管理这一模块，不讲用户管理了，角色管理这一块，是采用表格的形式来展示的，每次修改、添加用户却使用弹窗来实现的，发现弹窗真的是个好东西，又不占篇幅，又能阻塞代码
添加角色
角色添加会把当前所有的权限用属性的结果列出来，让用户可以一目了然地看到当前的所有权限以及权限的对应关系
总结
Since the code part involves secrecy, I will not post it, but they are all similar. Role-permission, everyone can have their own way of implementation, of course, many ways can be implemented, you can also use the configuration file, you can also use the ready-made permission framework, of course, you can also write one like me, as long as you like and Business needs. I wrote this blog today mainly because I spent a lot of time on the design of roles and permissions when I was doing this permission development before, but not much time for real development, so most of my blog is about permissions and permissions. The design and planning of role assignment mainly reminds me of the role of attracting others. I hope there will be a better solution for the permission development of my system. At the same time, I also hope that this blog can give some inspiration to those who have the same needs.
Q: What is the relationship between child permissions and parent permissions? Does the child permissions have all the permissions of the parent permissions plus their own additional permissions, or do they inherit part of the parent permissions.
Answer: Permissions generally have no inheritance relationship. The parent permission controls what the user sees on the home page, and the child permission controls the specific operation of a menu.