public class ForwardedHeaderFilter extends OncePerRequestFilter
There are security considerations for forwarded headers since an application cannot know if the headers were added by a proxy, as intended, or by a malicious client. This is why a proxy at the boundary of trust should be configured to remove untrusted Forwarded headers that come from the outside.
You can also configure the ForwardedHeaderFilter with
in which case it removes but does not use the headers.
|Constructor and Description|
|Modifier and Type||Method and Description|
Same contract as for
Typically an ERROR dispatch happens after the REQUEST dispatch completes, and the filter chain starts anew.
Use this property to enable relative redirects as explained in
Enables mode in which any "Forwarded" or "X-Forwarded-*" headers are removed only and the information in them ignored.
Can be overridden in subclasses for custom filtering control, returning
The dispatcher type
Whether to filter error dispatches such as when the servlet container processes and error mapped in
doFilter, getAlreadyFilteredAttributeName, isAsyncDispatch, isAsyncStarted
addRequiredProperty, afterPropertiesSet, createEnvironment, destroy, getEnvironment, getFilterConfig, getFilterName, getServletContext, init, initBeanWrapper, initFilterBean, setBeanName, setEnvironment, setServletContext
public void setRemoveOnly(boolean removeOnly)
removeOnly- whether to discard and ignore forwarded headers
public void setRelativeRedirects(boolean relativeRedirects)
RelativeRedirectFilter, and also using the same response wrapper as that filter does, or if both are configured, only one will wrap.
By default, if this property is set to false, in which case calls to
HttpServletResponse.sendRedirect(String) are overridden in order
to turn relative into absolute URLs, also taking into account forwarded
relativeRedirects- whether to use relative redirects
protected boolean shouldNotFilter(HttpServletRequest request)
trueto avoid filtering of the given request.
The default implementation always returns
protected boolean shouldNotFilterAsyncDispatch()
javax.servlet.DispatcherType.ASYNCintroduced in Servlet 3.0 means a filter can be invoked in more than one thread over the course of a single request. Some filters only need to filter the initial thread (e.g. request wrapping) while others may need to be invoked at least once in each additional thread for example for setting up thread locals or to perform final processing at the very end.
Note that although a filter can be mapped to handle specific dispatcher
web.xml or in Java through the
servlet containers may enforce different defaults with regards to
dispatcher types. This flag enforces the design intent of the filter.
The default return value is "true", which means the filter will not be invoked during subsequent async dispatches. If "false", the filter will be invoked during async dispatches with the same guarantees of being invoked only once during a request within a single thread.
protected boolean shouldNotFilterErrorDispatch()
web.xml. The default return value is "true", which means the filter will not be invoked in case of an error dispatch.
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException
doFilter, but guaranteed to be just invoked once per request within a single request thread. See
Provides HttpServletRequest and HttpServletResponse arguments instead of the default ServletRequest and ServletResponse ones.
protected void doFilterNestedErrorDispatch(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException
sendErroron the response. In that case we are still in the filter chain, on the same thread, but the request and response have been switched to the original, unwrapped ones.
Sub-classes may use this method to filter such nested ERROR dispatches
and re-apply wrapping on the request or response.
context, if any, should still be active as we are still nested within
the filter chain.