Dispatcher CORS configuration - gap in documentation | Community
Skip to main content
Level 4
October 29, 2018

Dispatcher CORS configuration - gap in documentation

  • October 29, 2018
  • 2 replies
  • 15947 views

Hi,

I've just worked through configuring our AEM dispatchers to support CORS requests and I think the Adobe documentation needs improvement.  Configuring a CORS policy via system/console was straightforward enough but while direct requests to our publish instances returned a valid response (with expected "Access-Control-Allow-Origin:..." in the response headers) requests via our dispatchers did not (and no CORS request handling was being logged in our publisher's output).

I couldn't understand the issue: it turned out additional dispatcher cache/headers are required but supporting​ info explaining this is unintuitive​.  I'd seen the documentation but didn't think I was at the point of worrying about caching - since i didn't yet have a valid response to cache.

Fortunately I stumbled upon this KB video - Adobe Experience Manager Help | Developing for Cross-Origin Resource Sharing (CORS) with AEM  - where the presenter says "...we add the CORS headers to the dispatcher config to allow our CORS headers to be passed through as well as cached...".  Eureka!

Could the documentation be improved to make this more obvious and a more explicit CORS dispatcher configuration section be used for this setting?

2 replies

smacdonald2008
Level 10
October 29, 2018

We will log a DOC Bug based on this thread!

Level 4
October 31, 2018

Hi thanks @smacdonald2008.

Actually this is proving more problematic than we first thought - some advice and further info from Adobe would be appreciated.

So far, I've only been able to get CORS request handling to work via the dispatcher if we add appropriate 'header' entries to the 'cache' section of the dispatcher config.  So whether we want to or not, we end up caching CORS response headers.  The problem is that in our use case we have an osgi CORS policy regex that allows a number of origins but because of the CORS response caching only the first requester will succeed until cache expiry (subsequent CORS requests from other origins fail since the cached origin is different to the current requester's origin (even though they are an 'allowed origin' under our policy)).

It is font files under etc/designs that are the allowed content and therefore good candidates for caching.

How can we solve this ? 

jonnow
Level 2
November 16, 2018

I am facing the exact same issue. There is a css that is used by multiple domains and CORS policy is requires on font files. Works when serving the font file from publisher but not after it gets cached on dispatcher.

Followed the same docs advising to add origin header cache on the dispatcher.

Rather useless because it will only cache the first origin header and causes all other subsequent origins to be blocked.

Is this a limitation of the dispatcher?

Level 4
November 19, 2018

smacdonald2008​ can Adobe help with any further info about my follow up point around CORS header caching?

Are there any other ways to address the problem that the first requesting origin is the one that gets written into the header cache (meaning subsequent requests from other authorised origins are blocked)?

Would having individual CORS policies for each allowed origin help - or would the caching problem still be there?  Are there other ways to configure the apache dispatcher to allow CORS response headers through - e.g. using the dispatcher clientheaders section?

jonnow
Level 2
November 20, 2018

Hi DorianHallward, I got it to work by adding this config to apache. Basically, if the request has origin from any of your whitelist domains, it will rewrite the header on the spot to allow that origin. The domain regex should match what you have in com.adobe.granite.cors.impl.CORSPolicyImpl.xml.

<IfModule mod_headers.c>

  SetEnvIfNoCase Origin "https?://.*\.(origin1.com|origin2.com|origin3.com)$" ACAO=$0

  Header set Access-Control-Allow-Origin %{ACAO}e env=ACAO

</IfModule>

Level 4
November 20, 2018

Thanks jonnow

so has your solution been to,

1. set osgi CORS policy

2. configure your apache/dispatcher cache section to enable CORS header pass through and cache CORS response headers in dispatcher

3. configure mod_headers in apache to overwrite any Access-Control-Allow-Origin response headers cached by the dispatcher and replace that header value with the matching entry from your whitelist?

If i've understood how it works that sounds great and i will give it a try.

Still feels like the aem/dispatcher implementation for cors support is broken!