If you are reading this article, chances are high you have encountered a CORS error somewhere on your community. This article will explain to you what a CORS error is, how you might be restricted by it as well as hopefully provide help for workarounds that can be used in order to achieve your desired results.
What is CORS?
Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.
Sometimes you may wish to programatically make calls to another remote server location in order to load resources e.g fonts - and use them within the community. You may also want to load other scripts (custom tracking events, Web 2.0 elements etc) for community use too. But by default this action is disabled on the inSided platform - this is unless the resources you are trying to load are also being loaded from a server with the same domain name.
To illustrate this; lets take this small example:
-
Corporation A has a community with a domain name of corporation-a.com.
-
The same company also has a Content Delivery Network (CDN) server which can be located on the url: corporation-a-cdn.com.
-
The company wishes to use this font from their CDN on the main community site.
-
They try to load the font via a normal XHR request from the CDN path.
-
The CORS error is thrown indicating that this has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
-
This is caused by the origin community server domain (corporation-a.com) being different to the domain in which the content is being served from (corporation-a-cdn.com).
Another example could be the loading of 3rd party scripts or dynamic content via AJAX calls from a domain different when compared with the origin.
Workarounds
So first and foremost the remedial action for this is to only load scripts from a Content Delivery Network on the same domain as the community. This will need to be factored into the decision regarding what community domain to use vs what domains corporate resources (fonts and scripts) are served from.
To demonstrate how to get the illustrative example above to work properly:
-
The community url of corporation-a.com is still used and remains unchanged, but the Content Delivery Network domain is changed to something like cdn.corporation-a.com. This way both the domains for the community and CDN are the same (corporation-a.com) as subdomains are treated as being on the same domain.
-
Or instead of using a Javascript XHR request to load the fonts, an @font-face CSS rule can just be added instead. This will bypass the CORS restriction and allow for fonts from other domains to be used on the main community. Please note that this will only work for fonts and not scripts or other resources fetched by an XHR request.