Introduction to Filter
Filter is also called a filter. It is the most practical technology in Servlet technology. Through Filter technology, WEB developers intercept all web resources managed by web servers: such as Jsp, Servlet, static image files or static html files, thereby achieving some special functions. For example, implement some advanced functions such as URL-level permission access control, filtering sensitive vocabulary, and compressing response information.
It is mainly used to preprocess user requests, and can also post-process HttpServletResponse. The complete process of using Filter: Filter preprocesses user requests, then hand over the request to the Servlet for processing and generates a response, and finally Filter post-processes the server response.
Filter function
1. Intercept the client's HttpServletRequest before the HttpServletRequest arrives at the Servlet. Check the HttpServletRequest as needed, and you can also modify the HttpServletRequest header and data.
2. Intercept HttpServletResponse before it reaches the client. Check HttpServletResponse as needed, and you can also modify the HttpServletResponse header and data.
How to use Filter to implement interception function
There is a doFilter method in the Filter interface. When the developer writes the Filter and configures which web resource to intercept, the WEB server will call the filter's doFilter method every time before calling the service method of the web resource. Therefore, writing code in this method can achieve the following purpose:
1. Let a piece of code execute before calling the target resource.
2. Whether to call the target resource (that is, whether to allow users to access the web resource).
When the web server calls the doFilter method, it will pass a filterChain object in. The filterChain object is the most important object in the filter interface. It also provides a doFilter method. Developers can decide whether to call this method according to their needs. If this method is called, the web server will call the service method of the web resource, that is, the web resource will be accessed, otherwise the web resource will not be accessed.
Filter development two steps
Write a java class to implement the Filter interface and implement its doFilter method.
Use and elements in the web.xml file to register the written filter class and set the resources it can intercept.
Introduction to web.xml configuration nodes:
The <filter-mapping> element is used to set the resource that Filter is responsible for intercepting. A Filter intercepts a resource can be specified in two ways: the servlet name and the request path for resource access.
<servlet-name> Specifies the name of the Servlet intercepted by the filter.
<dispatcher> specifies the way the resource intercepted by the filter is called by the Servlet container. It can be one of REQUEST, INCLUDE, FORWARD and ERROR, and the default REQUEST. Users can set multiple <dispatcher> sub-elements to specify Filter to intercept various ways of calling resources.
The value and its meaning that the child element can set is as follows
Filter chain
In a web application, multiple Filters can be developed and written, which are combined into one Filter chain.
The web server decides which Filter to call first according to the order in which Filter is registered in the web.xml file. When the doFilter method of the first Filter is called, the web server will create a FilterChain object representing the Filter chain and pass it to the method. In the doFilter method, if the developer calls the doFilter method of the FilterChain object, the web server will check whether there is still a filter in the FilterChain object. If there is, the second filter is called, and if there is no, the target resource is called.
Filter's life cycle
public void init(FilterConfig filterConfig) throws ServletException;//Initialization
Like the Servlet program we write, the creation and destruction of Filter is the responsibility of the WEB server. When the web application is started, the web server will create an instance object of Filter and call its init method to read the web.xml configuration to complete the object initialization function, thereby preparing for interception for subsequent user requests (the filter object will only be created once, and the init method will only be executed once). Developers can obtain FilterConfig object representing the current filter configuration information through the parameters of the init method.
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;//Intercept request
This method completes the actual filtering operation. When the client requests access to the URL associated with the filter, the Servlet filter will first execute the doFilter method. The FilterChain parameter is used to access subsequent filters.
public void destroy();//Destroy
The Filter object will reside in memory after creation and will be destroyed when the web application is removed or the server is stopped. Called before the web container uninstalls the Filter object. This method is executed only once during the life cycle of Filter. In this method, the resources used by the filter can be freed.
FilterConfig interface
When configuring filters, users can configure some initialization parameters for filters. When the web container instantiates the Filter object and calls its init method, it will pass in the filterConfig object that encapsulates the filter initialization parameters. Therefore, when developers write filters, they can obtain the following content through the filterConfig object method:
String getFilterName();//Get the filter name. String getInitParameter(String name);//Returns the value of the initialization parameter with the name specified in the deployment description. If there is no existence, return null. Enumeration getInitParameterNames();// Returns an enumeration set of names of all initialization parameters of the filter. public ServletContext getServletContext();//Returns a reference to the Servlet context object.
Filter use cases
Use Filter to verify user login security control
I participated in maintaining a project some time ago. After the user exited the system, he went to the address bar to access the history. According to the url, he could still enter the system response page. I checked and found that the request was not filtered and verified that the user login was logged in. Add a filter to solve the problem!
First configure it in web.xml
<filter> <filter-name>SessionFilter</filter-name> <filter-class>com.action.login.SessionFilter</filter-class> <init-param> <param-name>logonStrings</param-name><!-- Don't filter the login page --> <param-value>/project/index.jsp;login.do</param-value> </init-param> <init-param> <param-name>includeStrings</param-name><!-- Filter only the specified filter parameter suffix --> <param-value>.do;.jsp</param-value> </init-param> <init-param> <param-name>redirectPath</param-name><!-- Not via jump to login interface --> <param-value>/index.jsp</param-value> </init-param> <init-param> <param-name>disabletestfilter</param-name><!-- Y: Invalid filter--> <param-value>N</param-value><!-- http://www.manongjc.com/article/1613.html --> </init-param></filter><filter-mapping> <filter-name>SessionFilter</filter-name> <url-pattern>/*</url-pattern></filter-mapping>
Then write FilterServlet.java:
package com.action.login;import java.io.IOException;import javax.servlet.Filter;import javax.servlet.FilterChain;import javax.servlet.FilterConfig;import javax.servlet.ServletException;import javax.servlet.ServletRequest;import javax.servlet.ServletResponse;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;import javax.servlet.http.HttpServletResponseWrapper;/** * Determine whether the user is logged in, and if it is not logged in, exit the system* http://www.manongjc.com/article/1613.html */public class SessionFilter implements Filter { public FilterConfig config; public void destroy() { this.config = null; } public static boolean isContains(String container, String[] regx) { boolean result = false; for (int i = 0; i < regx.length; i++) { if (container.indexOf(regx[i]) != -1) { return true; } } return result; } public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest hrequest = (HttpServletRequest)request; HttpServletResponseWrapper wrapper = new HttpServletResponseWrapper((HttpServletResponse) response); String logonStrings = config.getInitParameter("logonStrings"); // Login to login page String includeStrings = config.getInitParameter("includeStrings"); // Filter resource suffix parameters String redirectPath = hrequest.getContextPath() + config.getInitParameter("redirectPath"); // No login to the turn page String disabletestfilter = config.getInitParameter("disabletestfilter");// Is the filter valid if (disabletestfilter.toUpperCase().equals("Y")) { // Invalid chain.doFilter(request, response); return; } String[] logonList = logonStrings.split(";"); String[] includeList = includeStrings.split(";"); if (!this.isContains(hrequest.getRequestURI(), includeList)) {// Only filter the specified filter parameter suffix chain.doFilter(request, response); return; } if (this.isContains(hrequest.getRequestURI(), logonList)) {// Do not filter the login page chain.doFilter(request, response); return; } String user = ( String ) hrequest.getSession().getAttribute("useronly");//Judge whether the user is logged in if (user == null) { wrapper.sendRedirect(redirectPath); return; }else { chain.doFilter(request, response); return; } } public void init(FilterConfig filterConfig) throws ServletException { config = filterConfig; }}In this way, all requests to the user can be completed, and the user login must be verified through this Filter.
Prevent Chinese garbled filters
When the project uses the spring framework. When different character sets are used in the current JSP page and JAVA code for encoding, there will be garbled problems with form submitted data or uploading/downloading Chinese name files. Then you can use this filter.
<filter> <filter-name>encoding</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name><!---used to specify a specific character set--> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name><!--true: Regardless of whether the request has specified a character set, encoding is used; false: If the request has specified a character set, encoding is not used--> <param-value>false</param-value> </init-param></filter><filter-mapping> <filter-name>encoding</filter-name> <url-pattern>/*</url-pattern></filter-mapping>
Spring+Hibernate's OpenSessionInViewFilter controls the switch of session
When hibernate+spring is used in conjunction with it, if lazy=true is set (delayed loading), then when reading the data, hibernate will automatically close the session after reading the parent data. In this way, when you want to use the associated data and child data, the system will throw a lazyinit error. At this time, you need to use the OpenSessionInViewFilter filter provided by spring.
OpenSessionInViewFilter mainly maintains the Session state until the request sends all pages to the client, and does not close the session until the request is completed, so as to solve the problems caused by lazy loading.
Note: The OpenSessionInViewFilter configuration should be written in front of the configuration of struts2. Because the tomcat container is loaded in sequence when loading the filter, if the configuration file first writes the filter configuration of struts2, and then the OpenSessionInViewFilter filter configuration, the loading order results in the session not being managed by spring when obtaining data.
<filter><!-- lazy loading enabled in spring --> <filter-name>OpenSessionInViewFilter</filter-name> <filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class> <init-param> <param-name>sessionFactoryBeanName</param-name><!-- Default. By default, the bean with id as sessionFactory from the spring container. If the id is not sessionFactory, you need to configure it as follows. Here, the SessionFactory is the bean in the spring container. --> <param-value>sessionFactory</param-value> </init-param> <init-param> <param-name>singleSession</param-name><!-- singleSession defaults to true, if set to false, it is equal to no use OpenSessionInView --> <param-value>true</param-value> </init-param></filter><filter-mapping> <filter-name>OpenSessionInViewFilter</filter-name> <url-pattern>*.do</url-pattern></filter-mapping>
Struts2's web.xml configuration
To use Struts2 in the project, you also need to configure a filter in web.xml to intercept requests and go to Struts2's Action for processing.
Note: If in Struts2 version before 2.1.3, the filter uses org.apache.struts2.dispatcher.FilterDispatcher. Otherwise use org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter. Starting with Struts 2.1.3, the ActionContextCleanUp filter will be abandoned, while the corresponding functionality is included in the StrutsPrepareAndExecuteFilter filter.
Three initialization parameters are configured:
<!-- struts 2.x filter --><filter> <filter-name>struts2</filter-name> <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class></filter><filter-mapping> <filter-name>struts2</filter-name> <url-pattern>*.do</url-pattern></filter-mapping>
Thank you for reading, I hope it can help you. Thank you for your support for this site!