Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 92 rates

Implemented in 4.5

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

Official Documentation Available

This topic is now covered in Filters > Security Callback .


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.

  • No labels