4.5

}Simplifies configuration of login callbacks and allows simpler WebDAV and RSS support. See [MAGNOLIA-3858@jira] and [MAGNOLIA-3863@jira].

{status}
h1. 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.

h1. 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.

h1. 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.

h1. 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.