The “security filter” is in charge of protecting URL, requesting authentication and optionally authorization.
In some cases, you may want to bypass this “security filter” and this can be done using the matchers parameter which is generally a list of matcher names. A matcher is generally defined in the security configuration.
The matchers can also be used to always apply some logic on the URLs, like adding some security headers.
2) Available matchers
A matcher can be defined by implementing the
Matcher interface. It has only one method:
boolean matches(WebContext context) to say if the “security filter” must be applied.
A few matchers are available (but you can of course develop your own matchers):
PathMatcherallows you to include/exclude some paths in/from the security checks
HeaderMatcherallows you to check if a given header is
nullor matches a regular expression
HttpMethodMatcherallows you to check if the method of the HTTP request is one of the expected defined methods.
3) Default matchers
Most pac4j implementations use the pac4j logics and matchers and thus the
DefaultMatchingChecker component. In that case, the following matchers are automatically available via the following short keywords:
deletekeywords for the related configurations of the
HttpMethodMatcher(if they do not already exist)
hstskeyword for the
nosniffkeyword for the
noframekeyword for the
xssprotectionkeyword for the
nocachekeyword for the
securityheaderskeyword as a shortcut for
csrfTokenkeyword for the
DefaultCsrfTokenGenerator(it generates a CSRF token and saves it as the
pac4jCsrfTokenrequest attribute and in the
allowAjaxRequestskeyword for a default configuration of the
Access-Control-Allow-Originheader set to
nonekeyword for no matchers at all.
These short names are defined as constants in
DefaultMatchers. You can override them with your own matchers using the same names.