25

I've already found some questions related to this topic but I've realised that none of them shed light on this topic.

Apparently the OncePerRequestFilter ensures that a request passes through the filter only once in the filter chain, but it's not exactly clear to me when the opposite would happen.

It would be nice to see some scenarios in which to use one or the other. Also an example on when and how the filter might be applied several times on the filter chain.

For e.g.

  1. For a JWT filter which implementation should be used and why?
  2. For a CORS filter which implementation should be used and why? etc.
Bogdan Emil Mariesan
  • 5,529
  • 2
  • 33
  • 57

2 Answers2

8

We expect that as soon as a request hits your project, you should authenticate and authorize it once. Then, if everything seems fine, this request and any other request from this context can be allowed to hit your APIs without the need to go through filters again. OncePerRequestFilter makes sure of it that this authentication process happens only once. If we don't use this, whenever we internally make a request to some other API in our project, the same authentication will happen again as all our APIs are having the same security filter

A common use-case is in Spring Security, where authentication and access control functionality is typically implemented as filters that sit in front of the main application servlets. When a request is dispatched using a request dispatcher, it has to go through the filter chain again (or possibly a different one) before it gets to the servlet that is going to deal with it. The problem is that some of the security filter actions should only be performed once for a request. Hence the need for OncePerRequestFilter over GenericFilterBean.

ABODE
  • 958
  • 2
  • 15
  • 13
4

The javadoc for OncePerRequestFilter states

As of Servlet 3.0, a filter may be invoked as part of a javax.servlet.DispatcherType REQUEST or javax.servlet.DispatcherType ASYNC dispatches that occur in separate threads. A filter can be configured in web.xml whether it should be involved in async dispatches. However, in some cases servlet containers assume different default configuration. Therefore sub-classes can override the method shouldNotFilterAsyncDispatch() to declare statically if they should indeed be invoked, once, during both types of dispatches in order to provide thread initialization, logging, security, and so on. This mechanism complements and does not replace the need to configure a filter in web.xml with dispatcher types.

So it's an additional "safety" feature implemented in Spring to make sure things work the same regardless of the environment. If you look at the classes that extend it, you'll notice there are lots; including CorsFilter. Not sure if there are Spring filters that don't extend it, probably not.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • could you give an example that doesn't fit the description in the Javadoc? "dispatches that occur in separate threads" I'm more interested into this flavour – Bogdan Emil Mariesan May 18 '18 at 13:33
  • 1
    The class javadoc lists the `ASYNC` as well as `ERROR` dispatches that are done in different threads. The idea being that if a request is fully executed in a single thread, there's no problems with creating a filter to handle that, but if the request uses different threads during its lifetime the default filtering mechanism isn't as obvious anymore. – Kayaman May 18 '18 at 13:43