User permission management design (1)

User Management permission design has always been a hot topic, because it involves almost every developed business system. I have found a lot of materials, and the core is basically the same: Role-based management. users, roles, modules, and permissions can be combined to form a powerful permission management system.

I recently designed a user permission design in a project. I would like to discuss it with you and share it with you.

Design Concept

My design ideas or functions I want to implement

1. User Permissions are controlled by roles. A user can have multiple roles.

2. When a user has different roles, the permissions should be the complementary sets of multiple roles.

3. A role has multiple modules

4. the user's front-end menu display is determined by the modules owned by the role. The operation menus displayed by different users on the front-end are different.

5. The function buttons on the page are defined according to the functions included in the module and controlled by the permissions of the module and role.

6. You can view the users and roles of a module and set their special permissions.

7. Special settings can be made for a single user

In my project, I basically achieved the above effects and functions, but I found some shortcomings in the actual process. Because the entire permission design is based on the database, when the data is read, when the data volume is large (I say the data volume is more than), it may have a certain impact on the performance. But in general, thousands of users and the like can still be tolerated. I will explain the shortcomings later.

Database Design

Basic Design:

1. First, design the database.

I guess everyone is familiar with the database design.

Basic Tables: User tables, role tables, module tables, menus, and administrator tables. If enterprise-related tables are involved, other auxiliary tables, such as organization structure tables and group tables, may be added as needed.

User

Administrator

Role

Module
(My module table takes into account the sub-module factors, so there will be depth. The parent module ID fields were developed later. Due to the change in thinking, the isrootmodule, I have not used functioncode. To make the entire permission system more universal, I have designed it separately into another table)

Menu (a menu is the function corresponding to the module: add, delete, modify, details, list, browse, export, import, and so on)

Business table: user-role table module-function table role-module table

To implement one user with multiple roles (1 to n), one role with multiple modules (1 to n), and one module with multiple functions (1 to n ), we need to add several related business tables. We have previously considered using views for implementation. In my personal opinion, it is best to use views only to read data and not to perform data operations. it turns out to be undesirable. Here we should note that repeated data input should be avoided in actual business operations. these tables are simple but critical.

User-role:

Role-module:

Module-function:

As you can see, the table structure is very simple, there are few fields, and the design is similar. It extracts the associated field IDs for data access.

View: user-role-module-function view

It may be strange to everyone. Why does member_role appear here. Because we only access the id value in the data table, and the corresponding rolename field does not include it, the view here is to get other required field data in the associated table. For the other two views, You should know their usage by name.

Stored Procedures: add, delete, modify, and list data for each table. Determine whether the same data exists.
(Cudlis-create, update, delete, ifexist, show, list)

I will not list the stored procedures one by one. It is very simple. You only need to write the following statements. Basically, you won't have too many problems in the development process. note: It is best to judge data duplication in the correlated business tables (User Role tables, module menus, role module tables, and try to avoid repeated data insertion) I will give you a list of services to be implemented:

User table: (insert, update, ifexist, show, delete)

User Role table: (insert, update, ifexist, delete, rolelistbyuserid, userlistbyroleid)

Role table: (insert, update, ifexist, show, delete)

Role module table: (insert, ifexist, delete, show, rolelistbymoduleid, modulistbyroleid)

Module table: (insert, update, ifexist, show, dlete, listbyrootmoduleid, listbymodulelevel)

Module menu: (insert, update, delete, functionlistbymoduleid)

When you directly obtain all the permissions of a user, you should have a separate procedure to obtain the corresponding data from member_role_module_function in the view, so that you can get what you want.

The database design part should be similar. I think this should be generic. In practice, I personally think there should be some improvements:

1. the module and function can be stored in a data field in the form of a string, this may save a lot of time and bring more convenience in your code writing (mainly using split () to replace frequent data acquisition services) I didn't think of this in my initial design. It was a bit of a mistake.

2. I have not considered how to allow the parent module to inherit the permissions of sub-modules for the presentation of permissions of N-level modules. However, I think the isrootmodule field can be used as an article, unfortunately, I did not expect to complete this field. When there are many sub-modules, will the front-end UI display be slow? I did not perform the test. With certain risks
But I haven't imagined or implemented a good way to display the front-end UI. What I can think of should be a good one like gridviewtree.

This permission design has been used in my project and has not found any problems for the moment. It will be helpful for other system integration for me in the future. As for how to implement business in C #, I personally think that as long as you know how the database is rounded up, the business implementation in C # is only a process of getting data. I will share this article with you later.

Http://www.dezai.cn/blog/default.asp? Logid = 231