You can solve all these problems by utilizing the PublisherConnector library. Please see:
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 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
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:
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();
string url = resXml.DocumentElement.GetAttribute("url");
url += "&d=mycompany.com";
The document.domain value will be set to the value of this querystring argument.
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: