The javax.servlet dependency is missing in your pom.xml. Add the following to the dependencies-Node: <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.0.1</version> <scope>provided</scope> </dependency>
In order to get HttpServletRequest#getParts() to work in a Filter in Tomcat, you need to set allowCasualMultipartParsing=”true” in the webapp’s <Context> element in Webapp/META-INF/context.xml or Tomcat/conf/server.xml. <Context … allowCasualMultipartParsing=”true”> Because as per the servlet 3.0 specification the HttpServletRequest#getParts() should only be available inside a HttpServlet with the @MultipartConfig annotation. See also the documentation of the … Read more
After couple of hours of struggling, I’ve finally found the solution. In short, ContentCachingResponseWrapper.copyBodyToResponse() should be called in the end of the filter method. ContentCachingResponseWrapper caches the response body by reading it from response output stream. So, the stream becomes empty. To write response back to the output stream ContentCachingResponseWrapper.copyBodyToResponse() should be used.
This AuthenticationFilter also runs when login.html is being requested. However, the code is redirecting to login.html once again instead of continuing the filter chain. This explains the infinite redirect loop. You need to let the filter just continue the request if the currently requested page is already the login page itself. E.g. public void doFilter(ServletRequest … Read more
Well, this is a pretty broad subject. As you’re starting off with homebrewed authentication, I’ll target the answer on homebrewed authorization. Role checking in Java/JSF is at its own relatively simple if the model is sensibly designed. Assuming that a single user can have multiple roles (as is often the case in real world applications), … Read more
If you’re homegrowing HTTP request authentication on top of JSF, then a servlet filter is really the best approach. JSF is “just” a MVC framework and nothing in the JSF API is been specified to filter incoming HTTP requests to check user authentication. On normal GET requests, a JSF managed bean is usually only constructed … Read more
First, you need to save the status code in an accessible place. The best to wrap the response with your implementation and keep it there: public class StatusExposingServletResponse extends HttpServletResponseWrapper { private int httpStatus; public StatusExposingServletResponse(HttpServletResponse response) { super(response); } @Override public void sendError(int sc) throws IOException { httpStatus = sc; super.sendError(sc); } @Override public … Read more
Servlet filters are implementation of the chain of responsibility pattern The point is that each filter stays “in front” and “behind” each servlet it is mapped to. So if you have a filter around a servlet, you’ll have: void doFilter(..) { // do stuff before servlet gets called // invoke the servlet, or any other … Read more
You can’t delete headers afterwards by the standard Servlet API. Your best bet is to just prevent the header from being set. You can do this by creating a Filter which replaces the ServletResponse with a custom HttpServletResponseWrapper implementation which skips the setHeader()‘s job whenever the header name is Content-Disposition. Basically: @Override public void doFilter(ServletRequest … Read more
No, you can’t use a regex there. According to the Java Servlet Specification v2.4 (section srv.11.1), the url-path is interpreted as follows: A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping. A string beginning with a ‘*.’ prefix is used as an extension mapping. A string … Read more