The filter can add some additional operations before the request arrives at the JSP or servlet or before the response is returned to the client. if multiple JSP pages and servlets need to perform the same or similar operation, we can extract the operation to a servlet filter, and intercept the JSP or servlet that you are interested in by matching the path.
Let's take a few examples of typical filter applications, which can be widely used by readers:
· Encoding conversion
The garbled problem has plagued many web application developers because Java-based Web applications may run on different Web applications, operating system platforms, or hardware servers, different environments have their own default encoding types. In the data conversion process, different default encoding is the cause of garbled characters. Therefore, data encoding and conversion are often required during JSP development. we can create a servlet filter for encoding conversion before the request enters the service program.
· Add a uniform title or footer
Some web pages require a uniform title header or footer. You can use the servlet filter to add a uniform title and footer to the web page before the response is returned to the client.
· Implement Security Control
After logging on to the system, the user information object is usually put into the session. You can use the servlet filter to determine whether there are user information objects in the session before the request enters the JSP or servlet. If yes, the user has logged on. If not, the user has not logged on. The request is redirected to the logon page.
Logincheckfilter. Java code
Package bookstore. servlet;
Public class logincheckfilter
Extends httpservlet implements Filter
...{
Public void dofilter (servletrequest request, servletresponse response
, Filterchain)
...{
Try
...{
// Convert the request and response types
Httpservletrequest httprequest =
(Httpservletrequest) request;
Httpservletresponse httpresponse =
(Httpservletresponse) response;
Boolean isvalid = true
;
String uristr =
Httprequest. getrequesturi (). touppercase ();
If (uristr. indexof ("login. jsp") =-1 &&
Uristr. indexof (
"Switch. jsp") =-1 &&
Httprequest. getsession (). getattribute (
"Ses_userbean") = NULL
)
...
{
Isvalid = false
;
}
If
(Isvalid)
...
{
Filterchain. dofilter (request, response );
} Else
...
{
Httpresponse. sendredirect ("/webmodule/login. jsp"
);
}
} Catch (servletexception SX)
...{
Filterconfig. getservletcontext (). Log (sx. getmessage ());
} Catch (ioexception iox)
...{
Filterconfig. getservletcontext (). Log (iox. getmessage ());
}
}
}
Because login. JSP is the user login page, and switch. JSP is the user login processing page. when accessing these two pages, user information objects are not generated yet. Therefore, these two pages should be excluded from the filter validation rules. we determine whether the request path is login. JSP and switch. JSP, such as 18th ~ 19 rows.
If not, you must check whether the session object of the page contains the object named with ses_userbean (row 20th ). if there is no object named with ses_userbean, redirect to the logon page (row 29th). Otherwise, the request is sent to the Target Program (row 26th) of the request ).
Open Web. xml and you will see the deployment description configuration of the logincheckfilter, as shown in bold below:
Deployment description and configuration information of the filter
<Web-app>
<Display-Name> webmodule </display-Name>
<Filter>
<Filter-Name> logincheckfilter </filter-Name>
<Filter-class> bookstore. servlet. logincheckfilter </filter-class>
</Filter>
<Filter-mapping>
<Filter-Name> logincheckfilter </filter-Name>
<URL-pattern>/* </url-pattern>
</Filter-mapping>
</Web-app>
<Filter-Name> Configure the name and implementation class of the filter, and <filter-mapping> Configure the Path Matching mode of the filter.