Sample code of spring AOP to implement permission verification function

There are many ways to realize the function of function permission verification. One is to use interceptors to intercept requests, and the other is to use AOP to throw exceptions.

First, use the interceptor to jump to the login interface when you are not logged in. Note that AOP cut in is not used here, but interceptor is used to intercept, because AOP generally cuts in service layer methods, and interceptor intercepts controller layer requests. It itself is also a processor, which can directly interrupt the transmission of requests and return to the view, while AOP cannot.

1. Use the interceptor to jump to the login interface when you are not logged in

1.1 interceptor securityinterceptor

1.2. spring-mvc. XML (interceptor configuration section)

It should be noted here that the path intercepted by the interceptor should preferably have a suffix, otherwise some static resource files are not easy to control, that is, the request should have a unified format, such as Do and so on, so the matching and filtering speed will be very fast. If not, for example, use / * * to intercept all requests, the page rendering speed will be very slow because the resource file is also intercepted.

2. Use AOP to realize function permission verification

For function permission verification, interceptors can also be used similarly, but they will intercept all requests. There is no good filtering function for requests that do not need permission verification, so AOP is used to specify the method to intercept requests that need verification.

2.1 section class permissionaspect

2.2 user defined annotation validatepermission

Note: AOP cuts in a method, not a controller request, so it cannot directly return to the view to interrupt the request of the method, but it can interrupt the execution of the method by throwing an exception. Therefore, in the before notification, if you directly return to continue the execution of the connection point method through verification, Otherwise, a custom exception accessdeniedexception is thrown to interrupt the execution of the connection point method. The exception can be captured by the exception handler of the system (which can be regarded as a controller) and jump to a view or a request. In this way, the purpose of intercepting requests can be achieved. Therefore, the exception handler needs to be configured.

2.3 spring-mvc. XML (exception handler configuration and AOP configuration)

2.4 comment on controller requests requiring functional verification

2.5 the controller to which the exception handler forwards the request forward: / accessdenied

2.6 when the request verification fails, the above controller returns the result itself

As follows:

{"info": "you do not have permission to operate on this!", "success":false}

2.7 function verification service example

Note: This is just to cut in all methods of the controller package and its sub packages with @ validatepermission and @ ResponseBody annotations. This is certainly not general enough. It should cut in the method with @ validatepermission and throw different exceptions by judging whether the method has @ ResponseBody annotation in the aspect class, If it is annotated with @ ResponseBody, throw the above exception and return JSON string. Otherwise, throw another custom exception and redirect the request to a legal view, such as error jsp .

Send / moduleaccess.com via client Do request. The method corresponding to the request has both @ validatepermission and @ ResponseBody, and has the function ID parameter FID. In this way, AOP can enter the method and execute dobefore notification. Through the function parameter FID, it performs permission verification on it in combination with the user ID. if the verification returns directly, the program continues to execute, otherwise it throws a user-defined exception accessdeniedexception, The exception is caught by the system (the exception handler needs to be configured) and issue the request forward: / accessdenied, and then the corresponding controller / accessdenied processes the request and returns a JSON containing the verification failure information to the client. In this way, the / moduleaccess.do request is sent. If the verification fails, it is forwarded to the / accessdenied request, otherwise it will be executed normally. It takes such a big circle to implement it.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.