Permission control implementation under AOP

Summary Aspect-oriented programming (AOP) is a new programming technology that makes up for the shortcomings of Object-Oriented Programming (OOP) in cross-module behavior. AOP introduces aspect, which encapsulates actions that affect multiple classes into a reusable module, which allows Program This module modularized the cross-cutting concerns to eliminate the problems caused by OOP. Code Chaos and decentralization enhance the maintainability of the system and the reusability of code. This article analyzes the implementation methods of traditional permission control, and studies the implementation methods of permission control under AOP.

KeywordsAOP; cross-concern; design mode; permission Control

Problems faced by OOP Application Development

The object-oriented technology solves the problem of role division in the software system. With the help of object-oriented analysis, design, and implementation technology, developers can convert the "term" in the problem field into objects in the software system, so as to naturally complete the conversion from the problem to the software.

However, some requirements in the problem field are not described in such a "term. For example, a problem occurs: Some methods in the system need to be checked for permissions, which are distributed in more than 40 classes. What should we do in the face of this demand? The most direct method is to create a class (or interface), put the permission verification function in it, and let all classes that require permission verification inherit this class (or interface ). if this requirement is raised later. the files to be modified are scattered in more than 40 files. Such a large modification volume will undoubtedly increase the chance of errors and increase the difficulty of system maintenance.

People realize that, traditional programs often show behaviors that cannot be naturally suited to a single program module or several closely related program modules, such as permission verification, logging, context-sensitive error handling, performance optimization, and design. this behavior is called "crosscuttingconcern) ", because it spans the typical responsibility boundaries in a given programming model. If you have used code for cross-concern, you will know the problems caused by the lack of attention. Because the implementation of cross-cutting behavior is scattered, Developers find that such behavior is difficult to make logical thinking, implementation and change.

Basic Idea of AOP

AOP is short for aspect oriented programming, which means Aspect-oriented programming, a new programming technology. AOP is actually a continuation of the gof design model. The design model tirelessly pursues decoupling between callers and callers. AOP can be said to be an implementation of this goal. It can solve crosscut problems that cannot be well solved by OOP and procedural methods, such as cross-cutting concerns such as transactions, security, and logs. In the future, when the system becomes more and more complex and the cross-cutting concerns become a big problem, AOP can easily solve the problem of cross-cutting concerns.

Figure 1 implement the module as a group of concerns

Generally, developers (architects) need to sort out system concerns to meet certain requirements of enterprise applications. Figure 1 vividly describes the focus, which can look at the system from the perspective of AOP aspect. For example, the business logic of persistence, logs, and applications is usually considered a problem that needs to be solved by applications. Therefore, they are generally taken into consideration. From the perspective of the entire system, it is usually composed of a large number of concerns.

We regard AOP as a continuation of OOP, rather than a competitor. Oop works well in general, but is lacking in specific fields: for example, if we have to apply the same event behavior for multiple objects and methods, we need to cut/paste the same code into every method. AOP allows us to encapsulate such problems into aspects (aspect) to better implement modularity. AOP defines the pointcut concept, allowing developers to think about the program structure from another perspective, thus making up for some defects of OOP: if you need to apply cross-cutting behavior to a group of methods, You Should intercept these methods.

In J2EE application development, we mainly use the Interception Capability of AOP, which provides us with the ability to add custom behaviors before/after method calls of any object, this allows us to deal with crosscutting concerns in enterprise applications (that is, concerns that act on multiple objects at the same time) and maintain a strong type (without changing the method signature ).

Permission control application implementation

For permission management, there are the following web implementation methods:

(1) Use filter to parse all incoming Uris, obtain the user information in the session at that time, and then use RBAC mechanism, compare the permissions required for this link with the user's permissions, and then perform corresponding processing. This method has many advantages: simple, easy to implement, and not very invasive to the system. Here, URL is the resource in RBAC. The disadvantage of doing so is that all data operations must be reflected through URLs, which is not well implemented in modern programs. If struts, xwork, or tapestry is used, it is not uncommon to use the same URL (in the browser's opinion) to process multiple tasks.

(2) Use a baseservlet (servlet + JSP Classic mode), baseaction (struts mode), basepage (tapestry mode), or basecontroller (springmvc mode ), filter all requests to perform permission operations before processing them. Let's take a look at it to know that this mode is essentially different from the filter mode. The advantages and disadvantages are the same as above.

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

Public somefunciton (){ // Permission judgment User user = context. getuser (); If (user. canexecutethisfunction ()){ // Do the business method //... } Else { Throw new permissiondeniedexception (); } }

This method can control the granularity of permissions to specific business methods, so its control capability should be powerful. We can see that the permission judgment part is almost independent for each method.

This implementation method that includes permission operation check before a specific function has many disadvantages:

(1) Each function class requires the corresponding permission verification code to confuse program functions with permission verification, which has close coupling and makes it difficult to modify extension.

(2) implement a corresponding proxy class for each function class in proxy mode. Although program functions and permission tests are decoupled, there are too many proxy classes involved in the permission test of a role, it is difficult to extend the modification.

J2EE container Implementation of permission Control

Before the concept of AOP was born, the J2EE specification had provided container implementation standards for permission control, as shown in the results of this change:

Figure 2 permission control J2EE container implementation

In the past, the permission proxy implemented by each application was required to be converted to the proxy Implementation of the entire container. The dynamic proxy API after jdk1.3 provides technical guarantee for this conversion implementation.

Obviously, permission control verification through containers can greatly simplify the design of applications, remove the permission concerns of the application system, and change permission control into the configuration of the J2EE container server.

In fact, the container permission implementation is also a way to solve the problem from one side. After the birth of the AOP concept, the permission control implementation has also brought about two changes:

(1) Implement the permissions at the J2EE container level, that is, the permissions of the container itself.

(2) Permission implementation at the J2EE application level.

The implementation of permission control at the container level seems to make J2EE developers feel no flexibility and scalability. In fact, J2EE containers like JBoss 4.0 have introduced the concept of AOP, this allows J2EE developers to directly manipulate container behaviors in their own application systems. The aspect introduced by AOP can be integrated into containers and application systems.

For J2EE application system developers, they must have a sufficient understanding of J2EE containers such as JBoss, because these methods are not J2EE standards, this knowledge and investment may become useless when it is ported to a new J2EE container (or it may be possible to expand J2EE standards in the future ).

Obviously, using AOP to implement permission control at the J2EE application system level is a major method to solve the above porting risks. However, the disadvantage is that you must start from scratch and it will not take a short time.

Permission control implementation under AOP

With AOP, the new business method can be written as follows:

Public somefunciton (){ // Do the business method //... }

Without additional permissions, this business method looks so clear and natural.

The operation on the permission is used as an advice, and the advisor is concerned with all business methods (may have a specific package). Then, the rest is done by RBAC and AOP. Through such separation, a vertical business method is divided into a more natural business method and a focus. This focus may be written as follows:

Public class permissioncheckadvice implements methodbeforeadvice { Public void before (method arg0, object [] arg1, object arg2) throws throwable { // Permission judgment If (! This. getcontext (). getuser (). canexcute (this, arg0 )){ Throws New permissiondeniedexception (); } } }

There may be a problem: how to obtain the context or the user of the context at that time? The answer is to use IOC (or dependency injection) to reverse pass the context or user as a parameter to the logical method. Of course, these variables need to be initialized before being passed in. This initialization can be performed in superservlet and saved in the application as a session Singleton. The following is an example of the spring configuration file:

<Beans> <! -- Bean configuration --> <Bean id = "businesslogicbean" Class = "org. springframework. AOP. Framework. proxyfactorybean"> <Property name = "proxyinterfaces"> <Value> ibusinesslogic </value> </Property> <Property name = "target"> <Ref local = "beantarget"/> </Property> <Property name = "interceptornames"> <List> <Value> thepermissioncheckbeforeadvisor </value> </List> </Property> </Bean> <! -- Bean classes --> <Bean id = "beantarget" class = "businesslogic"> <Property name = "user"> <your user Object> </property> </Bean> <! -- Advisor pointcut definition for before advice --> <Bean id = "thepermissioncheckbeforeadvisor" Class = "org. springframework. AOP. Support. regexpmethodpointcutadvisor"> <Property name = "advice"> <Ref local = "thepermissioncheckbeforeadvice"/> </Property> <Property name = "pattern"> <Value>. * </value> </Property> </Bean> <! -- Advice classes --> <Bean id = "thepermissioncheckbeforeadvice" Class = "permissioncheckbeforeadvice"/> </Beans>

Conclusion

AOP introduces aspect, which encapsulates actions that affect multiple classes into a reusable module, which allows programmers to modularize cross-cutting concerns, this eliminates code confusion and decentralization caused by OOP and enhances the maintainability and reusability of the system. With the Interception Capability of AOP, it provides us with the ability to add custom behaviors before/after any object method call, this allows us to deal with the excessive focus on permission control in enterprise applications and maintain a strong type (without changing the method signature), decoupling program functions and permission tests.