Betrieb hinter Proxy/Load-Balancer o.ä.

If the application server (e.g. Apache Tomcat) on which Xima® Formcycle is installed is running behind another server, e.g. a reverse proxy, a load balancer or similar, it should be checked that the information of a request is passed on to it unchanged. In concrete terms this means that both the Host header and the protocol used must be passed on unchanged by the intermediate servers. In most standard configurations, however, this is not the case because the requests are received by the intermediary server and sent to the application server as a new request. 

Manipulation of the host and the protocol by a reverse proxy.

The problematic scenario (see figure) is the following:

  1. The user calls the URL https://www.example.com/formcycle{}.
  2. The request is received and evaluated by the intermediate server.
  3. The intermediate server makes a new request to the designated server. However, since an internal request is made here, the call URL is changed to http://192.168.0.1/formcycle{}. This URL now arrives at the application server and no longer contains the required information about which URL was actually called by the user.

Since Xima® Formcycle interprets the original request URL of the user, especially when logging into a form, and this URL may not be determined correctly, it is necessary to configure intermediate servers accordingly.  Make sure that both the HTTP header Host and the protocol used (HTTP or HTTPS) are forwarded unchanged.

Example configuration Apache

For the correct configuration of an Apache server, which acts as a reverse proxy, two points are relevant and have to be stored e.g. in the configuration of the VirtualHosts:

  1. The instruction code language="none"ProxyPreserveHost On/code}} to get the originally called //Host// header 1. The separation of the individual protocols and its usage when forwarding to the application server. This means that for //HTTP// and //HTTPS// a separate VirtualHost with appropriate configuration must be used. This configuration, as well as any settings that may be necessary when using self-generated certificates, is briefly illustrated here: ((( {{code language="none"}} <VirtualHost www.example.com:80> ... # Enables retention of the originally called host up to the application server. ProxyPreserveHost On ... # Forwarding via HTTP ProxyPass / http://192.168.0.1/ ProxyPassReverse / http://192.168.0.1/ </VirtualHost> <IfModule mod_ssl.c> <VirtualHost www.example.com:443> ... SSLEngine on SSLProxyEngine On ... # Enables retention of the originally called host up to the application server. ProxyPreserveHost On # Deactivates the certificate check of the application server if necessary. # Necessary if the certificates are self-created. SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off ... # Forwarding via HTTPS ProxyPass / https://192.168.0.1/ ProxyPassReverse / https://192.168.0.1/ </VirtualHost> </IfModule> {{/code}} )))
Tags:
Copyright 2000-2024