Information Classification: External Restricted.
See https://www.chili-publish.com/security

Reverse Proxy

With the End of Life of CHILI publisher (On Premise) this information is obsolete, and only kept as reference.

CHILI publisher now lives on as GraFx Publisher in the platform of CHILI GraFx

What is a reverse proxy

In computer networks, a proxy server is a server (a computer system or an application) that acts as an intermediary for requests from clients seeking resources from other servers. A client connects to the proxy server, requesting some service, such as a file, connection, web page, or other resource available from a different server. The proxy server evaluates the request as a way to simplify and control their complexity. Today, most proxies are web proxies, facilitating access to content on the World Wide Web. (Source: Wikipedia)

A reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client as though they originated from the reverse proxy itself. While a forward proxy acts as an intermediary for its (usually nearby) associated client(s) and returns to them resources accessible on the Internet, a reverse proxy acts as an intermediary for its (usually nearby) associated server(s) and only returns resources provided by those associated server(s). (Source: Wikipedia)

http://en.wikipedia.org/wiki/Proxy_server
http://en.wikipedia.org/wiki/Reverse_proxy

Why you need a proxy server for CHILI Publisher

CHILI Publisher is made to be integrated. When it's integrated in another website, that website has a public domain name: e.g. www.chili-publish.com

In that public (or extranet / intranet) web application, CHILI is integrated for document editing. This integration is done through an iframe.
An iframe is a container, referring to another page / website / ...

In order to send Javascript calls from the main web application to the application in the iframe, you might need to send the calls to the same domain.
More and more browsers als closing up security.

At the time of writing, most browsers allow cross-domain scripting, when the embedded application is using the same sub-domain.
E.g. chili_app.chili-publish.com vs www.chili-publish.com

Since version 9 Firefox closed this security "leak". And now Javascript calls can only be sent to sites on the same subdomain.

How to setup

On the webserver of the public facing application, you can define an "application" (e.g. /CHILI/)
This application should be cought by the reverse proxy setup in the webserver, en redirecting traffic (internally on the webserver) to the real webserver.
When the service-webserver answers the request, the request is then again passed by the main webserver to the visitor.

The visitor won't notice what is happening behind the scenes, nor will the browser. 

The setup for each webserver can be different. Most of the CHILI customers use Microsoft IIS, Apache or NGINX Reverse Proxy on NGINX.

How to handle https offloading

The request should be made with an extra header. We support 2 standard ones: X_SSL, CloudFront-Forwarded-Proto and one custom one: Force-https-links

So in your reverse proxy, you'll want to add one of the following HTTP Headers in the forwarded request

HTTP Header

Value

HTTP Header

Value

X_SSL

decrypted=true

CloudFront-Forwarded-Proto

https

Force-https-links

ON



All information on this page must be treated as External Restricted, or more strict. https://www.chili-publish.com/security