How to make a server wide filter on Tomcat?

Question

At work, we've inherited this Java class which handles all SSO login operations. There's a FiltroSegurancaGlobal.class which is mapped to *, forcing everything with a annotation

@WebFilter(urlPatterns = { "/*" })

The class is deployed in a JAR with a few other classes to handle the whole SSO operation.

Recently I was requested to install and configure a git server for internal purposes, I found a really interesting solution GitBlit, which works like a charm.

Here's the thing, when I deployed it to the server somehow some requests are slipping through the filter. That seemed impossible so I changed the filter to nothing:

public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        System.out.println("filter hit");
}

While the whole application wasn't being loaded, the user wasn't being redirected to the log in page, none of the resources (css,js) were loaded, but the (index) still shows in the developer tools windows with some of the page.

How is this possible? Wasn't a deployed filter with "/*" urlPatterns supposed to filter ALL requests?

As mentioned bellow I tried changing the urlPatters using annotation first, then server's web.xml later:

@WebFilter({"/", "*", "/*"})

and then

<filter-mapping>
  <filter-name>FiltroSegurancaGlobal</filter-name>
  <url-pattern>/*</url-pattern>
  <url-pattern>*</url-pattern>
  <url-pattern>/</url-pattern>
</filter-mapping>

Nothing has changed.

By probing chrome I realized that the only file that seemed to come through the server was angular.js, by searching their github I found a NgController.java file which has an odd code segment:

public void renderHead(IHeaderResponse response) {
        // add Google AngularJS reference
        response.renderJavascriptReference(new ResourceReference(NgController.class, "angular.js"));

The actual class also implements IHeaderContributor, which is from the Apache Wicket package, not sure if this helps to troubleshoot the issue.

I also found this question which mentions FORWARD requests, I'm gonna try checking this out, but I'm still not sure what's going on.

Just a minor addition, it seems that the correct solution would be using Tomcat's Valve but that question has a comment mentioning that: [Filters]'re only overridable whenever webapp's /WEB-INF/web.xml has another one with same filter name.

Which is an impossible situation in this case, since I doubt the deployed app has a filter map with the same filter name.

I'll probably migrate the whole thing to the Valve Component to make sure it's server wide, but I still don't understand what's going on in this particular scenario.

ALSO: I forgot to mention that GitBlit has a console output when a user tries to connect, ex: 2016-05-13 13:53:38 [INFO ] 0 repositories identified with calculated folder sizes in 5 msecs and I just noticed that the filter hit system.out.println is being executed AFTER it, meaning somehow the request from the browser is not passing through it.

Answer 1

Upon closer inspection of this question, I've decided to migrate the servlet to a valve.

It was pretty straight forward.

I'll just mention that I had to add these two lines of code

    HttpServletRequest servletReq = valveReq.getRequest(); 
    HttpServletResponse servletRes = valveRes.getResponse();

To make the Valve work as expected, since the original filter has some rules based on the request and it would redirect the user if not authenticated.

Answer 2

I had the same problem and although I didn't find any answer to this problems I did some tests myself and I came to the conclusion that the /* url mapping on Tomcat's web.xml means anything below the root context.

Suppose this is what you have deployed on your Tomcat:

/ (root application)
/myApp1
/myApp2

If you then make a GET request to the URL /myApp1/users the filter won't be triggered because you are performing an operation on /myApp1 context.

If instead you make a GET request to the URL /myApp3/users then the filter will run, because now the context is /.

Unluckily, has I said, I have no source for this claim, apart from some personal tests and I don't quite understand how Tomcat default filters are supposed to work, so feel free to disprove me.