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

Let's assume you want to use Magnolia as content storage to serve content managed with Magnolia apps to independent applications located "outside" of Magnolia. For example, you want to use an AngularJS blog application to display blog posts managed with Magnolia and served via a REST API.

Magnolia and the Angular application are hosted on completely different systems and because browsers limit access to cross-origin resources, for security reasons your Angular application is not allowed to access content from the Magnolia host.

In today's browsers, it's possible to workaround this limitation using Cross-origin resource sharing.

The problem

The list of articles in your Angular blog app is empty despite the fact that articles are available in your Magnolia based content system.

Safari's error console shows what's wrong:

So the browser actively prevents accessing the REST API provided by Magnolia.

The solution: Magnolia CORS filter

By adding the CORS filter to the Magnolia filter chain, requests from your "external" blog app are allowed and the Magnolia REST API you provided is able to deliver the content you requested:


The Magnolia CORS filter is not an officially supported Magnolia module yet, but you can access the the source code on the Git repository and integrate the module into your Maven-based Magnolia project.

Location for the source code:

After adding this Magnolia module to your web app, you should see an entry for the filter in the Magnolia configuration.

Configuration options

By expanding the configuration node you can see the options available for the CORS filter.

Filter configuration

You have to provide at least the configuration options marked in bold. These parameters are added to the response header if the filter is triggered.

ParameterMeaning and values
allowOriginThis specifies the origin of the request (URL/host) and could be something like In the default configuration, the wildcard parameter * is used so all origins are allowed. See also the bypasses configuration below.
allowMethodsWhich HTTP verbs are allowed to make the request, in our example only GET. Could be  POST, GET, OPTIONS, PUT, DELETE, HEAD.
allowHeadersHeaders allowed for the request.
maxAgeOptional parameter, indicates how long the results of a preflight request can be cached in a preflight result cache.

This is the minimal set of configuration you have to specify for the CORS filter. In addition to that, you have to set the enabled flag to true, otherwise the whole filter is ignored (this is a Magnolia standard property in the filter section). The class property for the filter class also has to be provided but this is something that is normally not changed often.


A standard within Magnolia filter configuration is the possibility to specify bypasses - one or more definitions that define when a filter should be executed. See also the documentation for request processing and filters.

In the example configuration for our blog application we define that the filter should be ignored except for the two REST API calls we provide for retrieving all posts or a single article:

Please notice the not property we set within the bypasses configuration for the CORS filter. You can add more bypass definitions or delete the bypasses configuration completely.


The CORS filter is just an example provided by the Magnolia Professional Services team. At the moment, it's not officially supported by Magnolia. The module itself should be simple enough to understand and change the source code. If you need further assistance, please contact Magnolia

  • No labels


  1. Would be nice if this was available through the Nexus.

  2. OK, will put that on the list and hopefully it's there soon...

  3. Took a while because I first wanted to move it to another repository:







  4. Please see the official AddHeadersFilter available as of Magnoila 5.6.2 which provides most of the same functionality: Filters#AddingHTTPheaders