What is the second of the AOP series: AOP and permission control implementation

In the past, in the J2EE system, there were two main implementation methods: application implementation and J2EE container implementation.

 

Traditional application implementation

 

This is the most direct and traditional solution. Generally, a permission judgment statement is added before a specific method, as shown below:

 

 

 

Public class forumfactoryproxy extends forumfactory {
......
Public Forum createforum (string name, string description)
Throws unauthorizedexception, forumalreadyexistsexception
{
If (permissions. Get (forumpermissions. system_admin )){
Forum newforum = factory. createforum (name, description );
Return new forumproxy (newforum, authorization, permissions );
} Else {
Throw new unauthorizedexception ();
}
}
......
}
 

 

 

The above code is the code used to create the forum function in the jive Forum. Before creating the Forum, check the permission role. If the current user is a system administrator, you can create the forum.

 

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 tight coupling and makes it difficult to expand and modify.

 

2. if it is similar to jive, the proxy mode is used to implement a corresponding proxy class for each function class. Although the program function and permission test are decoupled, considering the permission test of a role, too many specific proxy classes are involved, making it difficult to modify extensions.

 

J2EE container implementation

 

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:

 

 

 

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 aspect. After the birth of the AOP concept, the permission control implementation has also brought about two changes:

 

1. J2EE container-level permission implementation, that is, the container's own permission implementation.

 

2. J2EE application-level permission implementation.

 

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. (How long does it take to use Bea's ejbc editing ?)

 

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.

 

Application permission control implementation under AOP

 

The permission implementation after the introduction of AOP is no longer as "backward" as the previous jive instance. We refactorying this instance as follows: Create an aspect for permission check

 

Private Static aspect permissioncheckaspect {

 

Private pointcut permissioncheckedexecution ():
Execution (Public Forum forumfactory. createforum (string, string ));

 

Before (): permissioncheckedexecution (){
If! (Permissions. Get (forumpermissions. system_admin )){
Throw new unauthorizedexception ();
}
}

 

}
 

 

 

This section of code is used to check whether the operation is permitted before the system runs the forumfactory. createforum method.

 

In the code, pointcut is triggered when the createforum method is executed. If there are other methods that need to be executed by the system administrator, the Code is as follows:

 

Private pointcut permissioncheckedexecution ():
Execution (Public Forum forumfactory. createforum (string, string) |
Execution (Public Forum forumfactory. deleteforum (string, string) |
......
Execution (Public Forum forumfactory. deletethread (string, string ));
 

 

 

The display of these methods is trivial and can be simplified as follows based on the aspectj Syntax:

 

Private pointcut permissioncheckedexecution ():
Execution (Public * forumfactory .*(..));
 

 

 

If you are interested, you can use AOP to reorganize the relevant permission proxy section in the jive forum. In addition, because jive does not introduce the role concept, the permission and user hardcode are encoded, the role concept plays an important role in how to decouple permissions from users and minimize the amount of hardcode.