Servlet Filter Introduction
Filters are Web application components that can be bound to a Web application. However, unlike other Web application components, the filter is "chain" in the process of handling the container. This means that they access an incoming request before the Servlet processor, and the outgoing response information is accessed before it is returned to the customer. This access allows the filter to examine and modify the contents of the request and response.
Filter Application Scenario: Create a model for new features of a Web application (can be added to a Web application or removed from a Web application without having to rewrite the base-level application code) Add new functionality to past code user-authorized Filter:filter is responsible for checking user requests, Filtering user illegal request log filter According to request: detailed record of certain special user requests responsible for decoding filter: including decoding of requests for non-standard encodings
Location used by filter:
Before a filter is placed on a web resource, it can intercept the incoming request before the request arrives at the Web resource it is applying (which can be a servlet, a JSP page, or even an HTML page) and intercept the output request before it returns to the customer. Filter: Used to intercept the request, between the client and the requested resource, in order to reuse the code. Filter chain, which is first configured in the Web.xml, which is called first. Some initialization parameters can also be configured in the filter.
Purpose of filter: to intercept the customer's httpservletrequest to check httpservletrequest as needed before HttpServletRequest arrives in the servlet, You can also modify the HttpServletRequest headers and data before HttpServletResponse arrives at the client, intercepting HttpServletResponse to check httpservletresponse as needed, Can modify HttpServletResponse headers and data
A filter can be responsible for intercepting multiple requests or responses: a request or response can also be intercepted by multiple requests. Verifying system logon permissions using filter
Here we use the way to verify the session, when a request to a module, first verify the current user's request whether there is a session exists, if there is, continue to access, if not, that is, jump to the landing page.
First step:
Write your own filter intercept class, blocking classes need to implement the filter interface of the servlet
public class Webfilter implements filter{
@Override public
void init (Filterconfig filterconfig) throws servletexception {
}
@Override public
void Dofilter (ServletRequest servletrequest, Servletresponse Servletresponse, Filterchain Filterchain) throws IOException, servletexception {
httpservletrequest request = ( HttpServletRequest) ServletRequest;
HttpServletResponse response = (httpservletresponse) servletresponse;
HttpSession session = Request.getsession ();
String Currpath = Request.getrequesturi (); The current request URL
if (Session.getattribute ("logined")!= null) {
filterchain.dofilter (ServletRequest, servletresponse);
} else {
response.sendredirect ("/login.jsp");
}
}
@Override public
Void Destroy () {
}
}
The Interceptor chain is used here, and when we configure multiple interceptors, the server assembles a chain according to the sequence of filters defined in Web.xml, and then executes one of the Dofilter () methods at a time.
Step Two:
Configuring the Custom Interceptor in Web.xml
Xml:
<filter>
<filter-name>webFilter</filter-name>
<filter-class> com.test.interceptor.webfilter</filter-class>
<init-param>
<param-name>skippath</ param-name>
<param-value>ok.jsp</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>webFilter</filter-name>
<url-pattern>/*< /url-pattern>
</filter-mapping>
In this way, we have configured our custom interceptor, if there are multiple interceptors, please pay attention to the order of interceptor configuration, interception will be in order from top to bottom intercept, in general, the processing of coded interceptor is configured on the top.
By using the above steps, you can access it through a URI at this point. At this point if you can get the logined value in the session, you will go directly to the next processing, otherwise directly into the login page. Thus completes the session the verification.