In this chapter, we will learn about the following:
Enabling CORS in WordPress, Drupal, Joomla!, and Adobe Experience Manager (AEM)
Enabling CORS in the WordPress.com SAAS platform
Drupal modules for CORS and methods using the API
The AEM package com.adobe.cq.social.commons.cors
Using rulesets in AEM to add CORS headers
Configuring the Sling Referrer filter in the AEM CRX Console
Web content management frameworks are often integrated with external platforms, APIs, and services. When the external source is hosted on a different domain, CORS is used to allow requests from the external local domain to the target domain of the web content management framework, without needing a proxy. We will look at techniques for allowing these requests.
When making a CORS request from the web content management framework as the local domain to a different target domain, it is either handled with custom code using the methods we covered in the earlier chapters, or a plugin may implement the headers and methods needed for the requests.
All the major content management frameworks offer a Software As A Service (SAAS) hosted/managed option. Since you do not actually control the server, and scripting is limited, implementing CORS may be difficult, or sometimes impossible.
In the SAAS platform WordPress.com, we shall see that CORS is very limited, and authenticated requests require explicit permission by the current user.
The Drupal SAAS platforms Drupal Gardens and Acquia Cloud Site Factory do not provide a way to implement CORS. There have been feature requests for adding CORS capability, so it may become possible.
It's unclear whether CORS is possible in the SAAS versions of Joomla! and Adobe Experience Manager.
The demand for the capability of CORS will likely be satisfied in these SAAS platforms eventually, so we recommend contacting support and asking them explicitly whether CORS can be implemented.
WordPress can be self hosted, or you could use WordPress.com, which is the hosted/managed SaaS platform for creating WordPress sites. Although incoming and outgoing CORS requests are possible in the self-hosted WordPress, the WordPress.com platform only allows incoming requests.
WordPress.com provides a REST API, which can allow incoming CORS requests via JavaScript/jQuery only; other languages are not supported.
You need to whitelist the domains you want to allow to make requests to your application in the dashboard for the site. Authenticated and unauthenticated requests are supported.
The REST API provides a way for other domains to interact with the WordPress.com application. Requests are made to the URI , which is the API endpoint for WordPress.com. There is no provision for making a CORS request from WordPress.com to another domain. That is a limitation of using the WordPress.com SAAS compared with the self-hosted WordPress...
Custom code is the best way to implement CORS in Drupal, using techniques we have covered. There are also some contributed Drupal modules for CORS. Be mindful of Drupal core API differences among versions: Drupal 6, 7, 8. When Drupal 8 is released, support for Drupal 6 will end.
CORS headers may be added to endpoints created in a custom module or in the template.php file in your theme.
The CORS headers can be added:
To enable CORS in Joomla!, you need to add the standard CORS header(s). There are a few ways to add the header(s), which are covered in the following sections.
Since Joomla! version 11.4, the core method to set headers is setHeader in the base class JapplicationWeb, which can be used to set the Access-Control-Allow-Origin header and can be used to set other headers.
The following example allows access from all domains with the wildcard:
setHeader('Access-Control-Allow-Origin', '*', true) : \JApplicationWebYou may find discussions regarding the use of JResponse::setHeader for CORS in Joomla!; however, it has been deprecated since Joomla! Version 11.4. Use setHeader in the base class JApplicationWeb instead.
While the previous sections examined using CORS in frameworks built with PHP, Adobe Experience Manager is built with Java.
In 2013, Adobe systems renamed the Adobe CQ WCM to Adobe Experience Manager (also known as Adobe AEM or just AEM).
AEM has a Java package for CORS. Another option is to allow domains to post to Sling in the CRX console; when domains are trusted this way, CORS is unnecessary. In some cases, such as when using Scene 7, CORS headers may need to be added with rulesets.
AEM includes a package named com.adobe.cq.social.commons.cors. The package contains four classes:
|
Classes in com.adobe.cq.social.commons.cors |
Description |
|---|---|
|
CORSAuthenticationFilter |
Adds CORS headers to HTTP responses |
|
CORSAuthInfoPostProcessor |
CORS authentication post processor |
|
CORSConfig |
Singleton configuration holder so that both the CORS filter and CORS post processor have access to the system settings |
|
CORSConstants |
CORS... |
