Decoupled practical applications-Permission Design

A very important purpose of system design is to reuse the system. Low coupling is the most effective means.

 

This article describes the decoupled applications through permission design, the most common topic in the Web application system.

 

To decouple, we must first abstract the permissions. Can permissions be abstracted?

 

In my opinion, permissions are generally divided into two categories ﹕

The first type is whether the user has the right to perform an action. For example, the administrator can delete the post and the personnel examiner can modify the attendance data. This type of permission is the simplest or the least problematic. Without a doubt, it can be abstracted for independent design.

 

Another type is called data permission. For example, a person can view the personnel information of a certain department, a person can review the orders of a certain factory, and a person has the permission to download a report. the application system is related to the specific application logic, which needs to be solved during system analysis and embedded in the program. When the business logic changes, you often need to modify the code logic.

Of course, this type of permission application can also be abstracted, but its coupling degree is relatively high. After abstraction, the reuse is at the coding level, such as encapsulating permission allocation, removing and obtaining code ﹐ however, you need to create a new permission class and use it in the business system.

 

This article focuses on the application of the first type of permission to describe the application of decoupling.

The first type of permission is actually the most widely used permission. The most common design for this type of permission is to divide roles, such as a BBS, with four roles: Administrator, Banzhu, common user, and anonymous user.. Each person is a role. The menus, pages, and buttons that each role can access are different.

Some small ones have relatively simple logic. Stable systems can use this method to greatly reduce permissions.

 

However, it is coupled.

 

For example, on the subscriber list page, bamboo may have a delete button next to each subscriber, which is not available to common users. Programmers often need this encoding ﹕

If (user is administrator or Banzhu)

Delete button. Visible = true

Else

Delete button. Visible = false

 

At first glance, there is no problem with this code. But at least a bit of uugly is the hardcode code that programmers are most jealous of: user is administrator or bamboo. Some people may say this will not have a big impact.

 

However, this at least gives our system the following assumptions ﹕

1: Only Administrators or bamboo can delete the posts. This assumption is very difficult to stand on. The system is constantly changing and it is easy to see a role named "Bamboo" or" Bamboo" someday ﹐ they can also be deleted...

2: The system is built on these fixed roles. I believe that in addition to judging the role code on this page, the system will surely be filled with such code elsewhere. Once it needs to be changed I had to find out all the code...

 

Once these assumptions change, the system will be dragged down by this coupling"

During my several years of programming, the number of requirements for permission modification is countless. Can a supervisor call me to open the attendance query permission for me? I want to see the Attendance Status of our department. Days ago, the attendance query is only available to the examiner, but more functions that can only be operated by the personnel Examiner are "insecure" in front of him. who knows if it will click the button in it?

 

You may say that the requirement analysis should be clear when you first develop a program. Now, follow the normal system maintenance process.

 

We can't say that he is a supervisor or a customer.

More importantly, in the end, we need to change the program, or we need to face the permission judgment code scattered in all corners of the system. Why did we leave our eyes blank at the beginning?

 

The solution is to abstract permissions and decouple them from a specific business system. When developing a system, you do not have to consider what roles the system has, who can do what they can, and who can do it. what. However, this part of requirements is removed.

For example, when writing the code for deleting a post, you do not need to write it down.

If (has Delete permission)

// Delete the sub-code

 

Instead, you can write and delete the content directly. I check whether you have the permission to delete the content. However, since your code is executed here, I assume that you have the permission to delete the content ﹐ I don't care about it, maybe you are happy, so that a common user can delete the post temporarily (as requested by the customer or supervisor)

 

In this way, all functions of the entire system are developed.

 

Now, when anyone enters the system, all the menus are displayed, and all the buttons are quite comfortable.

 

Now let's consider the user's permission requirements ﹕

User requirements can be divided into four roles: Administrator, Banzhu, common user, anonymous user

The administrator can do everything.

Bamboo can only be deleted

Normal users can remove bamboo

Anonymous Users can only access the browsing page

 

Create several tables, perform corresponding operations, write a method, pass in userid and function, and return true or false (I have introduced a specific solution in my previous post ).

 

Where is this permission control?

It's very easy, as long as you don't need to put it together with your business code, maybe you can do it in the fashionable way like AOP, or the simplest way, you can write a class, every time you call to determine the permissions.

 

In the web system, it is the simplest. As long as an access URL corresponds to a function, an httpmodule can be used to convert the URL before calling if the above permission judgment method is returned, true is returned, and false is redirected to the error page.

 

We can see that our application system is clean and our permission module is clean.

 

Finally, I would like to mention another situation that is often encountered when this permission scheme is used for Web pages, that is, the same page that I just mentioned may have different permissions, and you cannot avoid it in any way. that line

If (user is administrator or Banzhu)

Delete button. Visible = true

Else

Delete button. Visible = false

.

 

Yes.

 

However, from another perspective, we can understand that we don't regard this permission as a business logic. Now I am only providing features and need to provide two features, browsing and management. Well, I am write two programs. One show. aspx and one manage. aspx

 

Others will say you are ill

 

Indeed, it is almost the same code. Why do we need to write two programs?

No way. I will write a program.

Postlist. aspx

However, the access addresses of the two functions are ﹕

Post. aspx? Type = show

Post. aspx? Type = manage

 

That line of code is also cleverly changed ﹕

If (request ["type"] = "manage ")

Delete button. Visible = true

Else if (request ["type"] = "show ")

Delete button. Visible = false

 

In this way, you can see that when programmers write code on this page, they are completely active and no longer ask system analysts: Boss, who has the permission to delete posts?

 

If you say to the boss that the program you want has been written, the browsing and Management pages are respectively...

How do you use it? Permission? What do you care about me?

 

Haha ﹕)

 

Now, we are welcome to discuss it.

From -- http://www.cnblogs.com/tsoukw/archive/2008/05/29/1210050.html