ÃÛ¶¹ÊÓƵ

Transcript

Let’s take a look at the Cross Origin Resource Sharing functionality or, as it’s usually referred to, CORS, that was introduced in AEM 6.3. So, for this I’ve created a simple HTML page that makes an AJAX call using JQuery to my AEM publish instance. This AJAX call collects the JSON representation of a page and then injects the AEM publishers page title into my HTML pages DOM.

Two things are important to note here: The first is that I am accessing my HTML page through www.example.com:8000. This is just a simple http server that I started up on my local instance. The second is that I’m accessing my AEM publish server through a completely different domain and that’s AEM-publish.local. Due to browser restrictions, Javascript-initiated requests to other domains must be CORS-enabled. Do note the preferred approach is to host cross-resource accessing web applications on the same domain or subdomain, which negates the need for CORS entirely. But if the web applications must be hosted on discrete domains, CORS is needed. Let’s take a look at what happens with our test page when CORS is not enabled. So, for this, I’ll open up my Network tab so we can watch our network traffic and click the button which issues the AJAX request to our AEM publish instance. The first thing we see is that our page title is not AJAX’d in. We can take a look at our response and our response does have the JSON that we expect. But if we go with the Javascript Console, we’ll see we have an error stating that the AJAX request is not allowed access to the content. Let’s fix this by adding a CORS policy configuration to our AEM publish instance. So, I’ll go ahead and Copy the Origin that is issuing this AJAX request, jump over to my Configuration Console on my AEM publish instance, locate the ÃÛ¶¹ÊÓƵ Granite Cross-Origin Resource Sharing Policy which I configure and create a new configuration. Under Allowed Origins, I’ll add my www.example.com:8000 which is where the AJAX requests are originating from. I can also add an Allowed path so that only content under /content/we-retail allows CORS-based access, or reduce the Allowed Methods to only GET since that is the only method that I am using in my Javascript. And lastly, I’ll uncheck Supports Credentials since I’m only making anonymous requests. I’ll Save these changes and you can see that we have a new policy created. Let’s jump back to our example.com page.

We’ll clear our Console and Network and issue the request again and, once again, it appears that it didn’t work. So, let’s take a look at why this might be. Let’s look at our request. In our Response Headers, we don’t have our Access Control Allow Origin header present. The reason for this is because we’re accessing AEM Publish through Dispatcher. And since this is an anonymous request to JSON, it’s cacheable. So, to resolve this, we must add a Headers configuration to allow the relevant access control headers to be passed through, as well as cached, at Dispatcher. So for this, I’ll add all of the access control headers that CORS uses. We can Save our changes and restart our web server.

I’ve cleared our cache for good measure.

Let’s jump back to our example.com page, then clear Consoles and network traffic and re-request the page. Now you can see that Experience, which is the title of the page we’re requesting, is being collected and injected into the DOM. If we look at the Response Headers, we can see we have our Access Control Allowed Origin set.

If we go back into our Dispatcher cache, we can see that we’re caching the actual Response Headers as well, so subsequent requests also work.

Keep in mind that all the normal Dispatcher caching considerations apply, so make sure you’re only caching headers where those headers will be identical for any user accessing that resource. If this is not the case, the request should not be cacheable. Also, remember if caching of CORS headers is enabled, you’ll need to invalidate the appropriate pieces of the cache whenever a CORS policy configuration changes.