Reputation: 2056
I am implementing a filter for security reasons.... The point that the page gets frozen and I don't know exactly why because the filter in fact is not still doing anything !
<!-- spring security csrf -->
<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>fr.telecom.support.context.DevicesSecurityFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Here my filter:
public class DevicesSecurityFilter extends DelegatingFilterProxy {
public DevicesSecurityFilter() {
// TODO Auto-generated constructor stub
}
public DevicesSecurityFilter(Filter delegate) {
super(delegate);
}
public DevicesSecurityFilter(String targetBeanName) {
super(targetBeanName);
}
public DevicesSecurityFilter(String targetBeanName,
WebApplicationContext wac) {
super(targetBeanName, wac);
}
public void doFilter(ServletRequest request,
ServletResponse response,
FilterChain filterChain) throws ServletException, IOException {
System.out.println ("do Filter...");
//super.doFilter(request, response, filterChain);
}
}
Upvotes: 0
Views: 222
Reputation: 691625
The filter is doing something: it prevents the request from going to the next filter/servlet in the chain, and doesn't send anything to the response. So it basically intercepts all requests and responds with a blank response to all of them.
For the filter to be "transparent", its doFilter()
method must contain
filterChain.doFilter(request, response);
or, since it's a DelegatingFilterProxy, it shouldn't have any doFilter() method at all, and instead let the parent's doFilter method implementation do its job: delegating to the Spring bean it's configured to use. In fact, you shouldn't even create subclasses of DelegatingFilterProxy: as its name indicates, it works, on its own, by delegating to a Spring bean. The Spring bean should be the one doing the filtering job.
By overriding the doFilter()
method, you're preventing that delegation to happen.
Upvotes: 4