Magnolia CMS uses the Java filter concept introduced in the Java Servlet specification version 2.3. A filter captures and processes a request before it reaches a servlet. Filters typically do not themselves create responses but provide universal functions that can be "attached" to any type of servlet or JSP page.

• Magnolia CMS filter chain
• Dispatching

Filters provide the ability to encapsulate recurring tasks and modularize code. They can also transform a response from a servlet or a JSP page. A common task is to format data sent back to the client, such as sending WML instead of HTML.

Some functions filters can perform:

• Authentication based on user identity.
• Logging, auditing, tracking, personalization.
• Image conversion, scaling maps.
• Data compression.
• Localization.

Magnolia CMS filter chain

The basic idea behind the filter chain is that the filters will be executed one by one until a filter decides that it can fulfill the request. This is a Magnolia CMS specific implementation of a standard Java filter chain.

In the diagram above you can see the following filters:

• Context. The first filter in the filter chain is the ContextFilter. It initializes MgnlContext which is local to this request and available on every further filter. The context provides a lot of useful functions.
• URI Security. Checks if the request is coming from an authenticated user and if the user is authorized to access the requested URI.
• Cache. The CacheFilter manages the cache. It checks if a requested resource is already stored in the cache to avoid recreation of the resource. If the resource is in the cache, then it will be written to the response and the filter chain stops. If the resource is not found in the cache, then the filter passes the request on to the CMS part of the chain.
• CMS filter chain. Next we arrive at the filter chain which does the page rendering and delivery. The filters in this sub-chain are grouped so they can share a co-bypass definition.
• Aggregator. The AggregatorFilter analyzes the request, selects the content from the repository and stores it in the AggregationState:

Request URI target	Stored in AggregationState
Page	Content node of the requested page. Page template.
Paragraph	Content node of the requested paragraph. Paragraph template.
NodeData	NodeData object of the requested data, for example binary.

• Rendering. Finally, the RenderingFilter is responsible for delivering the requested resource. If the requested resource is data such as a file then the data is just streamed to the response. If the requested resource is a page, then the Rendering Filter calls the rendering engine.

The main filter MgnlMainFilter is a single filter which in turn executes a chain of other filters. The chain is not configured in web.xml but in the config workspace at /server/filters.

In the filter configuration you can again have single filters or filter chains. A filter chain consists of a list of single filters represented by child nodes. A filter node has a class property which specifies the implementing class and can optionally have an enabled property.

The individual filters in the standard installation are covered in Magnolia CMS core filters.

Dispatching

Here are the default dispatching rules of the main filter which will execute on requests, errors and forwards but not on includes. For each of the rules you can define whether the filter should be executed when requesting a resource served by the container (toWebContainerResources), for example JSP pages. Whether a resource is a Web container resource or a Magnolia resource is defined in /server/webContainerResources/mappings. By default, any resource in docroot and JSP pages are Web container resources.

By default, a filter maps to any URI (/*). Concrete mappings can be defined as follows:

In addition, you can define bypasses using Voters. This example shows that the URI for the login form is bypassed in the uriSecurity filter.

For more, see Magnolia CMS core filters.