JavaScript Security Considerations

Embedding the CHILI Editor and communicating using JavaScript is a trivial thing to set up.

However, when the embedded editor is loaded from a different domain (or even sub-domain), there are security limitations to what the browsers will allow. This is due to same-origin policy, which blocks JavaScript between <iframe> and the window unless they have the same origin.

You can solve all these problems by utilizing the PublisherConnector library. Please see:

Warning

CHILI publisher Online does not support REST API calls from client browser to your environment. Typically, this is called an AJAX request. Trying to do this from the client browser will cause a cross-origin resource sharing preflight request. If the origin is not the same, the request will fail, and so will your AJAX request.

This means all REST API calls must be routed from the client server to a backend system and then to CHILI.

There are security reasons why this behavior is not currently supported.

There are three possibilities:

1: The portal and CHILI are hosted on the same full domain (as different sub-applications/folders)

For example:

portal = http://www.my-web-shop.com/PORTAL
CHILI = http://www.my-web-shop.com/CHILI

Solution:

In this case, there is no issue at all. However, this is not possible with CHILI publish Online without having a reverse proxy. We do not officially support reverse proxies.

2. The portal and CHILI are hosted on the same main domain, but different sub-domains

For example:

portal = http://portal.my-web-shop.com/
CHILI = http://chili.my-web-shop.com/

Solution:

In this case, you should use PublisherConnector.

3. The portal and CHILI are hosted on completely different domains

For example:

portal = http://www.my-web-shop.com/
CHILI = http://www.my-chili-installation.com/

Solution:

In this case, you should use PublisherConnector.

Summary

For the situations listed above, you should use the PublisherConnector library. This library uses postMessage() to allow communication between the window and the <iframe>. However, below we list two historical solutions. Keep in mind that these solutions are not officially supported.

Working on different sub-domains

Deprecated

The document.domain setting has been listed by Monzilla as deprecated. It is strongly suggested you do not use this solution. If you wish to use a sub-domain, we suggest using the PublisherConnector library to communicate with the <iframe>.

There are possibilities for communication when both pages are on different sub-domains:

To allow access across sub-domains (browser version permitting), you'll need to follow some additional steps. Both pages need to execute the following javascript:

document.domain = 'mycompany.com';

In your own page you can of course add this yourself. As for the "editor.aspx" page, you can append the domain to be set using a "d" argument in the querystring.
For example:

        string res = ChiliWebService.ws.DocumentGetEditorURL(ChiliWebService.key, docID, wsID,vpID,cID, chkViewer.Checked,chkAnonymous.Checked);
        XmlDocument resXml = new XmlDocument();
        resXml.LoadXml(res);

        string url = resXml.DocumentElement.GetAttribute("url");
        url += "&d=mycompany.com";

The document.domain value will be set to the value of this querystring argument.

URL Forwarding

Note

CHILI does not officially support setting up a proxy both in support and in functionality. There are some security reasons a solution might consider a proxy. However, it strongly suggested to avoid this method unless 100% necessary.

As the limitations on security are client-based (within the local browser), you can get around them by providing the client with a single domain (even though internally the portal and CHILI are hosted on different servers/domains).

Essentially, you will set up a sub-directory of your main URL (the one your users log in to), which gets resolved on your network (or that of your service provider) to the URL of CHILI. For example:

User logs in to:

http://www.my-web-shop.com

This portal needs to connect to CHILI on:

http://www.my-chili-installation.com/CHILI

To allow JavaScript communication across iframes, you set up a URL forwarding rule to (internally) rewrite:

Now, CHILI (and the url you can use in iframes) is available on the www.my-web-shop.com domain.

See Reverse Proxy on Apache for a sample configuration for Apache

See Reverse Proxy on NGINX for a sample configuration for NGINX

See Reverse Proxy setup for IIS for WIndows webservers