The implementation of privilege control under AOP

Problems in OOP application development

Object-oriented technology solves the problem of role partitioning in software system. With the help of object-oriented analysis, design and implementation technology, developers can transform the "noun" in the problem domain into objects in the software system so that the transformation from problem to software is done naturally.

However, some of the needs in the problem area are not described by such nouns. For example, the problem is that some methods in the system need to be checked for permission, and this method requires permission checking to spread among more than 40 classes. What should we do in the face of this demand? The most straightforward approach is to create a class (or interface), place the function of the permission validation in it, and have all classes that require permission validation inherit this class (or interface). If this requirement is later proposed. The areas that need to be modified are scattered across more than 40 files. Such a large amount of modification will undoubtedly increase the chance of error, and increase the difficulty of system maintenance.

It is recognized that traditional programs often exhibit behaviors that do not naturally fit into a single program module or several tightly related program modules such as permission checking, logging, context-sensitive error handling, performance optimization, and design patterns, and so on, which we call " Crosscutting concerns (Crosscuttingconcern) because it spans the typical boundaries of responsibility in a given programming model. If you have used code that is used for crosscutting concerns, you will know the problems that are caused by the lack of modularity. Because the implementation of crosscutting behavior is decentralized, developers find this behavior difficult to make logical thinking, implementation, and change.

The basic idea of AOP

AOP is the abbreviation of Aspect oriented programming, meaning aspect-oriented programming, a new programming technology. AOP is actually a continuation of the GOF design pattern, and the design pattern tirelessly pursues the decoupling between the caller and the callee, which can be said to be an implementation of this goal. It solves crosscutting (crosscut) issues that are not well addressed by OOP and procedural methods, such as transactional, security, log, and crosscutting concerns. As future systems become more complex and crosscutting concerns become a big problem, AOP can easily address crosscutting concerns.

Figure 1 implements the module as a group of concerns.

Often, to meet the needs of an entire enterprise application, developers (architects) need to sort out the system's concerns. Figure 1 Graphically describes the focus, which can look at the system from an AOP aspect perspective. For example, persistence, logging, and application business logic are often considered problems to be solved by applications. So they usually look at it as a point of concern. From the perspective of the whole system, it is often composed of a large number of attention points.

We view AOP as a continuation of OOP, not as a competitor. OOP works well in common situations but lacks in specific areas: for example, if we have to apply the same transaction behavior to multiple objects and methods, we need to cut/paste the same code into each method. AOP allows us to encapsulate this type of problem into aspects (aspect) for better modularity. AOP defines the concept of "pointcut" (pointcut), which allows developers to think about the structure of a program from another perspective, thus compensating for some of the pitfalls of OOP: if you need to apply crosscutting behavior to a set of methods, you should intercept these methods.

In Java EE application Development, we mainly use AOP interception (interception) capabilities, it provides us with "the method of any object before/after the custom behavior," the ability to This allows us to handle crosscutting (crosscutting) concerns in enterprise applications (that is, focus on multiple objects at the same time) and remain strongly typed (without changing the method signature).

Application implementation of permission control

For permissions management practices, on the web implementation, there are the following:

⑴ uses filter to parse all incoming URIs and obtains the user information at that session, then through the RBAC mechanism, the rights required by this link are compared with the permissions of the user, and then processed accordingly. There are many benefits to this approach: simplicity, ease of implementation, and a weak intrusion into the system. The URL here is the resource in RBAC. The disadvantage of this is that all operations on the data must be represented by URLs, which are not well implemented in modern programs. If you use struts, xwork, or tapestry, it is no surprise that you use the same URL (which the browser appears to) to handle multiple tasks.

⑵ utilizes a baseservlet (servlet+jsp Classic mode) or baseaction (struts mode) or basepage (tapestry mode) or Basecontroller (SPRINGMVC mode), All requests are filtered for permission to operate before being processed. A little look at it tells you that this pattern is not fundamentally different from the filter. Advantages and Disadvantages ditto.

Then, if you want to implement more granular permission operations, and be precise to the permissions of a method, the typical practice is as follows:

public someFunciton() {
　 //权限判断
　 User user = context.getUser();
　 if (user.canExecuteThisFunction()) {
　　 // do the business method
　　 // ...
　 } else {
　　 throw new PermissionDeniedException();
　 }
}