Embedding the CHILI Editor and communicating using JavaScript is a trivial thing to set up.
But 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 window unless the dom
There are three possibilities here:
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
In this case, there is no issue at all, but this is not possible with CHILI publish Online without having a reverse proxy.
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/
In this case, a workaround exists (see lower), to allow cross-frame scripting.
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/
In this case, cross-frame scripting is only possible by setting up a URL forwarding rule (see lower)
Working on different sub-domains
There are possibilities for communication when both pages are on different sub-domains:
- myportal.mycompany.com
- mychili.mycompany.com
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
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:
This portal needs to connect to CHILI on:
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