ASP. net mvc + EF framework + EasyUI permission management series (13)-Permission Design

The previous series of blogs can be said to be the essence of our series of blogs, so the blog we wrote today is the essence of our essence, because I started to analyze the permission design, how can we design a good permission and why we need to design it? In this blog, I hope everyone can give their opinions on my design. Of course, permissions are a lot of information that can be found on the Internet, I wrote it based on another platform. At the end, I will send out his website. I hope you can support me. Let's introduce our modules today.

1. What are permissions ??

(1) If you say permissions to many new programmers, they will mistakenly think that you are talking about user logon restrictions. I have met many such people, but I may not miss it, in fact, at the beginning, I thought so too. I also thought that the permission was a user login. However, when I was working in Changchun last year, our director (Xu **) did not say the name here, design personal privacy (if you're fine, you can do it yourself). Hey hey, he asked me to study this and then write a document, it took me several days to complete this. Finally, our Group discussed how to extend the permissions of our project, so we should not think that the permissions are user logon. This is wrong. Let's look at my explanation of permissions.

(2) permissions have nothing to do with user logon, but to use user data, permissions are to request a service (request address, request method, request Action, when requesting WebService, etc.), before the request, we first need to verify whether your user has the right to access the current request. If you have the right, we will allow you to access, but you cannot access this request.

(3) Let's give a very typical example to illustrate permissions (I don't want to think about it myself, it's everywhere. let's remember the example that I told us at the beginning ), for example, if a soldier in our army has a warehouse with weapons wants to fetch them from the warehouse, can he take them? The answer is, of course, no. Why? For example, when the soldier was scolded by his leaders, the soldier went directly to the warehouse and gave me a missile, then I took the missile and got the leader's missile without knowing where to get it. Is that all right? Of course not, so the weapons in our warehouse cannot be given to anyone. When you go, first check whether the warehouse owner has the permission. If not, you certainly cannot enter, this is an example of a simple permission, which is also far-fetched, but it is okay to understand it. I remember that the old horse was very funny.

(4) Only three objects (users, roles, and operations) are the most important entities in a permission, if we figure out the relationship between the three of them, you can basically handle the permission module.

2. Permission Preliminary Design

(1) As mentioned above, only three tables (user, role, and Operation) with the heaviest permissions are involved ), other Relational Tables are extended around these three modules.

(2) I will divide it into several categories to introduce the differences between various creation permissions. I wrote this blog with reference to yukai, And the content is basically the same, I wrote some detailed information on it. I hope you will forgive me. I have always attached great importance to copyright issues, so I declare that I should follow the steps of others to explain it.

3. Role-Based Design

(1) The role-based design involves a user table (Kencery, HYL) that stores user data and a role table (Super administrator, common administrator, and common customer) it stores the role information and generates an intermediate table in the middle. This is a simple role-based design.

(2) The above design scheme is the most common scheme, especially when the permissions on various websites are not obvious. Most of the above schemes are used, that is to say, if a user has this role, you can access some pages, in this design scheme, the relationship between users and roles in the database is many-to-many (one person can have multiple roles and one role can be owned by multiple people ), how can we express the many-to-many relationship? We can only add one intermediate joined table. The table structure is as follows:

(3) through the above figure, I fully explained the content I explained above. Because this is a relatively simple answer, it will be explained here, here we have designed many-to-many relationships in the database. If you are not clear about anyone, you can leave a message below or directly add my QQ Group to ask me (if I want to answer it again ), I will not explain many to many here.

(4) the disadvantage of this design scheme is that the permission control is limited. If it takes a long time, the intermediate table will become very large, redundant, and inaccurate.

4. Operation-based Design

(1) What is operation design? Every Action in our system is abstracted into an Action. When we click a button, it is an Action, as long as we perform any operation on the website (or system) as an Action, does the current user have the right to perform the operation, this action can be accessed only when it is associated with the user.

(2) If we follow the above design, we will have a lot of actions. If a system is a little larger, we will not know where to go, in this case, the data in our Action table will be very large and will not meet our needs. The table structure of this design mode is as follows:

5. Role-based operation design

(1) through the 4 design scheme, we can feel that the data in the Action table will be very large if we design it like that. Can we solve this problem, of course, this is acceptable. We can group this Action again. At this time, we will propose the role. What is the role? continue.

(2) role: as long as you create a role, this role will be associated with a group of actions. If the user joins this role, then, do users have all the actions associated with this role, that is, you can access the actions associated with this role. Therefore, a role can also be called an action group.

(3) Let's soften the role and operation. The table structure of this design method is as follows:

6. Permission design combining 4 and 5

(1) When we see the role-permission-based design above, most people may think that this design is already very good, but what I want to say is that although it is good, it is not perfect, what our programmers want is perfection, so where is it? The following is an example:

(2) For example, if our company is looking for short-term workers, that is, people who have been working for one or two months, when they come to the company, we need to give these employees access to the internal system of our company. At this time, we will add a zero-time job role according to the above design, however, this zero-time role is completely unnecessary, because they are only waiting for a while, so I don't think it is necessary to create a role for them. When we leave, we need to delete the role again, at this time, we need to design a permission that is more compliant with this rule, and a permission that combines 4 and 5 is born. Let's take a look at the role of this permission in detail.

(3) This permission adds a table to the user and action. This table is the user's special permission table, in the previous design, we used roles to associate users and permissions (you can refer to the 5th methods). Now we have an action table between users and actions. The table structure of this design method is as follows:

7. system permission Design

(1) through the above (1), (2), (3), (4), (5), (6) introduction, I believe that you have almost understood the design of permissions, so you may wonder what kind of permissions I use to implement them. Four types of permissions are described above, here, of course, we are designed according to the last permission. Only such permission design can be called a good permission design, so we will not talk much about it, we started to build the permission design for this project.

(2) When we develop a project, our database fields may not be fully considered. At this time, we need to add fields at the end. This problem is very common, because user requirements are changing, we do not need to worry about this. We only need to make our project highly scalable or reserve several additional fields, but it's not easy for everyone to come here.

(3) The permission tables designed by MVC and WebForm are different. Here I am targeting the permissions designed by MVC, if you want to design permissions for WebForm, you need to consider adding some fields on this basis.

(4) In summary, the final design page of user permissions is as follows:

8. Summary

(1) In this blog, we have designed our permission model. For example, we believe most users can still understand it. In fact, this blog is mainly based on the blog written by yukai, it is only written more specifically for my project, and more detailed, hoping to set up like.

(2) In the next blog, we will start to describe how to build the EasyUI framework at the front end. When we build this framework, I will give an example. I will show it to you later, I hope you will understand.

(3) Let's write it here today. I hope you can give valuable comments to my blog. I will be very happy to discuss it with you. If you have any questions, you can add my group, find me in the group and study it together.