AOP and permission control implementation
Mountain bridge http://www.jdon.com 2004/01/10
In the J2EE system, there are two main implementations of access control systems: application implementation and J2EE container implementation.
Traditional application implementation
This is the most direct, traditional solution, usually adds a permission judgment statement before the specific method, as follows:
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 a code that creates a forum function in the JIVE Forum. Before creating the forum, the permissions role check, if the current user is a system administrator, you can realize true creation.
This implementation of the implementation of the permission operation inspection before the specific function has many disadvantages: 1. Each function class requires the corresponding permission inspection code, confuses the program function and permission inspection, and there is a close coupling, expands the modification difficulty. Big. 2. If a JIVE is similar to the proxy mode, a corresponding proxy class is implemented for each function class. Although the program function and permission test are decoupled, it is tested from a role, involving too many specific proxy classes. And the extension modification is difficult.
J2EE container implementation
Before the AOP concept is not born, the J2EE specification has provided container implementation standards for permission control, which is shown below:
It turns out that the permissions of each application implementation proxy turn into the entire container's proxy implementation, where JDK1.3 has provided technical guarantee for this conversion implementation.
Very obvious, through the container implementation of permission control verification can greatly simplify the design of the application, separating the application system's permission attention, turn the permissions control into the configuration of the J2EE container server, specific technical details Reference My Book "Java Practical System Development Guide "Chapter VI.
In fact, the permission implementation of the container is also a way to solve the problem from a cut surface. After the AOP concept is born, the permission control implementation has also brought two direction changes: 1. J2EE container level permission implementation, that is, the container itself Permissions implementation. 2. J2EE application level permission implementation.
Permission Control seems to have a J2EE developer feels no flexibility and scalability in the vertical level of J2EE developers, and it is like the J2EE container such as JBoss 4.0, which has introduced the AOP concept so that J2EE developers can directly manipulate the container in their own application. Some behaviors. The container and application system becomes an integral due to the ASPECT introduced by AOP. (How much time if you want to waste using a BEA EJBC?)
For J2EE application system developers, it is possible to do the above realm. The necessary conditions must have enough understanding of JBoss's J2EE containers, because these methods are not J2EE standards, which may be ported to new J2EE containers, these knowledge and The input is useless (it is also possible to expand its standard in the future). Obviously, using AOP implementation J2EE application system level permission control is a major approach to solving the above-described transplant risk, but the disadvantage is that it must be started from zero, it will not be short.
Application permission control under AOP
The permission to introduce the AOP concept is not the "backward" of the previous Jive instance, and we reorgan this instance (refactorying) as follows:
Create an Aspect, specifically for permission check, as follows:
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 segment code function is to check if there is permission operation when the system runs the ForumFactory.createForum method.
The condition of the PointCut triggered in the code is executed by the createforum method. If there are other methods that require the system administrator identity, it will be written 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);
These methods are trivial, according to the AspectJ grammar, simplified as follows: private pointcut permissioncheckedexecution (): Execution (public * forumfactory. * (..));
Interested people can use the relevant permissions in the JIVE forum use AOP reunion, in addition, because JIVE does not introduce role concepts, leading to user hardcode, how to implement permissions and user decoupling, minimize HardCode, The concept is an important role in which the concept is induced. This is another research topic.
