"Struts2": Interceptor control of the actual combat rights

The previous blog introduced the concept of interceptors and some of the basics of Struts2 and custom interceptors, but how exactly is the interceptor applied in the actual project, perhaps you are still confused, then this blog we will come up with actual combat, but also a summary of the interceptor and application practice.
When we are doing any information management system, we can not avoid to control the rights, the identity of the logged-in user and the permissions to verify, do not let the non-legal users arbitrarily change our data and programs, to ensure the security of the system. Such a very common function, we want to use the STRUTS2 interceptor to implement the permission check, when the viewer needs to request to perform an action, the application system needs to check whether the user is logged in, and whether there is sufficient permissions to perform the operation.
In this demo, we require the user to log in, and the user must be the specified user name to view a view resource in the system, otherwise, the system goes directly to the login page. For such a requirement, the permission validation logic can be performed before each action executes the actual processing logic, but this practice is not conducive to the reuse of the code, because most of the rights validation code in the action is similar, so it will be more convenient and flexible to put these authorization code in the Interceptor, also more professional.
Check whether the user is logged in, usually by tracking the user's session to complete, through the Actioncontext can access to the properties in the session, The invocation parameter of the Intercept method of the interceptor makes it easy to access the Actioncontext instance associated with the request.

Let's write the code for the permission validation Interceptor class first, as follows

Permission check blocker inherits Abstractinterceptor class public class
Authorityinterceptor
	extends abstractinterceptor
{
	/ /Intercept Action handling method public
	String intercept (actioninvocation invocation)
		throws Exception
	{
		// Get request related Actioncontext instance
		actioncontext ctx = Invocation.getinvocationcontext ();
		Map session = Ctx.getsession ();
		Remove the user attribute in session,
		string user = (string) session.get ("user");
		If you are not logged in, or if you are logged on with a username other than admin, return to login if
		(user! = null && user.equals ("admin"))
		{
			return Invocation.invoke ();
		}
		If not logged in, the server prompt into the actioncontext
		ctx.put ("Tip", "You are not logged in, please enter the Administrator account login System");
		Returns the logical view of LOGIN return
		Action.login;}
}

As can be seen from the above code, first through the actioninvocation parameter to get a reference to the user's session instance, and then take out user property, by judging the value of the property to determine whether the user login to the system, so as to determine whether the need to transfer to the login page.
By implementing the above authorization-verification interceptor, you can use the interceptor in the configuration file to configure the action that need to implement permission control, so that it has the function of permission control. For details on how to define and apply the action in the Struts.xml file, see the following configuration:

<package name= "Lee" extends= "Struts-default" > <!--user interceptors are defined under this element--<interceptors> <!--defines a name
		Interceptors for authority--<interceptor name= "authority" class= "Org.ljw.app.interceptor.AuthorityInterceptor"/> </interceptors> <!--Define global result---<global-results> <!--when returning to the login view name, go to the loginform.jsp page--&
			Gt <result name= "Login" >/WEB-INF/content/loginForm.jsp</result> </global-results> <action name= " Login "class=" org.ljw.app.action.LoginAction "> <result name=" Error ">/web-inf/content//error.jsp</ Result> <result>/WEB-INF/content/welcome.jsp</result> </action> <!--define an action named Viewbook , its implementation class is Actionsupport---<action name= "Viewbook" > <!--return Success view name, go to viewbook.jsp page--<result >/WEB-INF/content/viewBook.jsp</result> <interceptor-ref name= "Defaultstack"/> <!--applying custom interceptors--&G
			T <interceptor-ref name= "Authority "/> </action> <action name=" * "> <result>/WEB-INF/content/{1}.jsp</result> &lt ;/action> </package>

The above action, named Viewbook, does not specify the class property, the Actionsupport class is used by default, and when the action is configured, only one result map is specified, specifying that the system returns the success string and the system is transferred to the Viewbook page. However, the JSP page corresponding to the login view name is not configured.
Considering the reusability of the Interceptor, the system may need permission control for each page, so the result map of login can be defined as a global result map, and the configuration method looks at the above code. If you want to simplify the configuration of the Struts.xml file and avoid repeatedly configuring the interceptor in each action, you can put the interceptor together with the STRUTS2 default interceptor stack, defined as the new default interceptor stack Mydefaultstack, so that you do not have to repeatedly define permission validation blocking in each action The default, which embodies the idea of abstraction and encapsulation, is the same as when we have to write code to extract the duplicate code to encapsulate the reuse.