Preventing unlisted users from operating — a simple implementation based on struts 2 interceptor

Generally, our web applications are allowed to operate only after the user logs in, that is, we do not allow non login authenticated users to directly access some pages or function menu items. I still remember my practice a long time ago: check whether there is a value in the session in a JSP page (of course, the user name or user object will be stored in the session in the user login logic). If the user information in the session is empty, redirect to the login page. Then introduce this JSP in all other pages except the login page that need to verify that the user has logged in.

For example, we put the code to check whether the user logs in into a JSP page, such as checkuser jsp

The login page is login jsp

Assuming that the login is successful, jump to the menu page menu jsp

Checkuser is introduced JSP, so that when a user attempts to access the menu without logging in JSP page will be forced to login JSP page.

Of course, the above method is feasible, but it is too ugly and troublesome. Later, I learned that JSP or HTML pages other than the login page can be placed in the WEB-INF directory, so that users can't directly click the URL in the browser to access the page. However, what if someone knows our action name and method name in some way? Should we check whether the user is logged in in each method of action? It's stupid just to think about it. Fortunately, we have a struts 2 interceptor.

Let's see how to implement it first.

We write an interceptor class that inherits methodfilterinterceptor.

In struts Fill in the XML file:

Among them, < param name = "excludemethods" > gologin, login < / param > the configured filtering method means that the interceptor has no effect on the methods. In my case, gologin is the way to jump to the login page. Login is the method to verify the user name and password, in which the authenticated user name will be put into the session. Yes, that's all we need to do. Isn't it convenient?

I would like to summarize here:

1. In struts 2, all interceptors inherit the interceptor interface.

2. After the interceptor is written, it should be in struts XML file. If the interceptor is used to intercept an action, the interceptor is placed after the result of the action.

3. If we don't add interceptors, struts 2 will add default interceptors for us. If we specify an interceptor, our own interceptor will replace the default interceptor, so we can't enjoy some of the functions provided by the default interceptor. So, I usually add the default interceptor. For example, in the above configuration items, add < interceptor ref name = "defaultstack" > < / interceptor ref > to action

4. The interceptor interface has three methods: init, destroy and intercept. But generally we don't care about init and destroy methods. So struts 2 provides us with a simplified interceptor class: abstractinterceptor, which implements the init and destroy methods. We only need to implement the intercept method.

5. About interceptor stack. The interceptor stack can be regarded as a "big" interceptor, which is composed of several interceptors. Think of it as a reference like an interceptor.

6. Method filter interceptor, You need to inherit the methodfilterinterceptor class (that is, the interceptor class used in our example here). You can specify which methods the interceptor intercepts (use < param name = "includemethods" > method1, method2 < / param >), or which methods the interceptor does not intercept (< param name = "excludemethods" > method1, method2 < / param >)

The above article to prevent the operation of unlisted users -- a simple implementation based on struts 2 interceptor is all the content shared by Xiaobian. I hope it can give you a reference and support more programming tips.