Implemented in 4.5
Simplifies configuration of login callbacks and allows simpler WebDAV and RSS support. See MAGNOLIA-3858@jira and MAGNOLIA-3863@jira.
Rationale
Currently, one can configure multiple login callbacks by using CompositeCallback
. With a fairly complex configuration, this allows to configure different callbacks based on the requested urls (typically /.magnolia
will be protected by the regular Magnolia login form, while a protected but public section of a website will redirect a login form from the website itself).
On top of the complex configuration, there are at least two drawbacks to the current configuration:
- One can only select a different callback based on a url pattern.
- Depending on which filter is hit, the patterns are different, especially in multi-site configurations (because UrlPatternDelegate#match uses
AggregationState.getCurrentURI()
, which returns a value that can change depending on where the filter is in the chain.
Current workarounds
The WebDav module's WebdavAwareUriSecurityFilter
uses 2 techniques to work around this: it checks the existence of a WebDav-specific request header, and uses a pattern matching against the user-agent: if either condition is true, it forces the usage of a BasicClientCallback
(response.setHeader("WWW-Authenticate"...
), otherwise it uses the regular mechanism.
Existing problems
Authenticated feeds for RSS are also a problem (MGNLRSSAGG-31@jira), because you can't expect users to manually subscribe to a feed by adding their credentials in the url. It seems most clients respond fairly well to a Basic auth, though.
Proposed solution
Add an accepts(HttpServletRequest request)
method to HttpClientCallback
, and allow configuring a chain of such call backs at security level filter; first call back that accepts the request processes it.
The WebDav module could then use the regular security filters, but insert its custom callback early in the chain; same thing for the rss module. (which could "accept" the request based on a list of known user agents, or a url pattern or extension...)
I'm also assuming that this would make it simpler to have a multi-site aware callback.
Additionally, we're introducing an extra filter to "catch" the 401/403 status as well as AccessDeniedException}}s; existing subclasses of {{BaseSecurityFilter
will not handle the callbacks anymore, but merely set an http status. The new filter will have callbacks configured and handle them.