Inhalt
Sollte der Anwendungsserver (z.B. Apache Tomcat), auf welchem formcycle installiert ist, hinter einem weiteren Server wie z.B. einem Revers-Proxy, einem Load-Balancer oder ähnlichem betrieben werden, ist zu beachten, dass die Informationen eines Aufrufs unverändert an diesen übermittelt werden. Konkret bedeutet dies, dass sowohl der Host-Header als auch das verwendete Protokoll durch die zwischengeschalteten Server unverändert weitergereicht werden müssen. In den meisten Standardkonfigurationen ist dies jedoch nicht der Fall, da die Anfragen vom zwischengeschalteten Server entgegengenommen und als neue Anfrage an den Anwendungsserver gestellt werden.
Der problematische Ablauf (siehe Abbildung) ist hierbei folgender:
- Der Benutzer ruft die URL https://www.example.com/formcycle auf.
- Die Anfrage wird vom zwischengeschalteten Server entgegengenommen und interpretiert.
- Der zwischengeschaltete Server stellt eine neue Anfrage an den dafür vorgesehenen Server. Da hier jedoch ein interner Aufruf stattfindet, kommt es zur Änderung der Aufruf-URL zu http://192.168.0.1/formcycle. Diese URL kommt nun beim Anwendungsserver an und beinhaltet nicht mehr die benötigten Informationen welche URL vom Benutzer eigentlich aufgerufen wurde.
Da FORMCYCLE vor allem bei der Anmeldung an einem Formular die ursprüngliche Aufruf-URL des Benutzers interpretiert und diese ggf. nicht ermittelt werden kann, ist es nötig, zwischengeschaltete Server entsprechend zu konfigurieren. Hierbei ist darauf zu achten, dass sowohl der HTTP-Header Host als auch das verwendete Protokoll (HTTP oder HTTPS) unverändert weitergereicht werden. Ebenso muss das korrekte Weiterleiten von WebSocket-Verbindungen gewährleistet werden. Als Alternative zu den konkreten Protokollen kann der zwischengeschaltete Server ebenso über X-Forwarded Header mitteilen, welches Protokoll die Anfrage ursprünglich verwendet hat.
Beispielkonfiguration Apache
Für die korrekte Konfiguration eines Apache-Server, welcher als Revers-Proxy agiert, sind drei Punkte relevant und z.B. in der Konfiguration der VirtualHost´s zu hinterlegen:
- Die Anweisung ProxyPreserveHost On zum Erhalt des ursprünglich aufgerufenen Host-Headers
- Die Separierung der einzelnen Protokolle und deren Verwendung bei der Weiterleitung zum Anwendungsserver. Dies bedeutet, dass für HTTP und HTTPS ein eigener VirtualHost mit entsprechender Konfiguration benutzt werden muss.
- Konfiguration der bedingten RewriteRule für die Weiterleitung der WebSocket-Verbindungen jeweils über WS und WSS. Hierbei verwendet FORMCYCLE standardmäßig die entsprechenden Ports des Servlet-Containers (WS-Port = HTTP-Port, WSS-Port = HTTPS-Port).
Für die Einstellungen am Apache ist es notwendig die entsprechenden Module zu aktivieren. Folgende sind mindestens erforderlich:
- proxy
- proxy_http
- proxy_wstunnel
- rewrite
Weiter Informationen zu den Modulen des Apaches finden Sie hier.
Die oben erläuterte Konfiguration ist, ebenso wie die ggf. nötigen Einstellungen bei der Verwendung selbsterstellter Zertifikate, hier kurz veranschaulicht:
<VirtualHost www.example.com:80> ... # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver. ProxyPreserveHost On ... # Weiterleitung über HTTP ProxyPass / http://192.168.0.1/ ProxyPassReverse / http://192.168.0.1/ ... # Weiterleitung der WebSocket-Verbindung über WS RewriteEngine on RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L] </VirtualHost> <IfModule mod_ssl.c> <VirtualHost www.example.com:443> ... SSLEngine on SSLProxyEngine On ... # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver. ProxyPreserveHost On # Deaktiviert falls nötig die Prüfung des Zertifikats des Anwendungsserver. # Nötig falls es sich um selbsterstelle Zertifikate handelt. SSLProxyVerify none SSLProxyCheckPeerCN off SSLProxyCheckPeerName off SSLProxyCheckPeerExpire off ... # Weiterleitung über HTTPS ProxyPass / https://192.168.0.1/ ProxyPassReverse / https://192.168.0.1/ ... # Weiterleitung der gesicherten WebSocket-Verbindung über WSS RewriteEngine on RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L] </VirtualHost> </IfModule>
Verwenden von X-Forwarded Headern für unverschlüsselte Kommunikation
Wenn der zwischengeschaltete Server das Senden von X-Forwarded Headern unterstützt und der FORMCYCLE hostetende Servlet-Container (z.B. Tomcat) diese Header auswerten kann, ist es möglich die Kommunikation von zwischengeschaltetem Server und FORMCYCLE auch über ein anderes Protokoll zu konfigurieren. Sowohl beim vorgeschalteten Server als auch beim Servlet-Container muss das Verwenden dieser Header konfiguriert sein. Nähere Informationen zur Konfiguration finden sich in der Dokumentation des jeweiligen Produktes. Bei dieser Variante ist es nicht mehr notwendig im Tomcat Zertifikate zu hinterlegen. Es folgen hier zwei Konfigurationsbespiele für Apache und nginx.
Konfigurationsbeispiele
Im Apache kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen VirtualHosts beispielsweise wie folgt konfiguriert werden:
<VirtualHost www.example.com:80> ... RequestHeader set X-Forwarded-Port "80" RequestHeader set X-Forwarded-Proto "http" ... # Weiterleitung über HTTP ProxyPass / http://192.168.0.1/ ProxyPassReverse / http://192.168.0.1/ ... # Weiterleitung der WebSocket-Verbindung über WS RewriteEngine on RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L] </VirtualHost> <IfModule mod_ssl.c> <VirtualHost www.example.com:443> ... SSLEngine on SSLProxyEngine On ... RequestHeader set X-Forwarded-Port "443" RequestHeader set X-Forwarded-Proto "https" ... # Weiterleitung über HTTPS ProxyPass / http://192.168.0.1/ ProxyPassReverse / http://192.168.0.1/ ... # Weiterleitung der gesicherten WebSocket-Verbindung über WSS RewriteEngine on RewriteCond %{HTTP:Upgrade} websocket [NC] RewriteCond %{HTTP:Connection} upgrade [NC] RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L] </VirtualHost> </IfModule>
Bei nginx kann für das Mitsenden der entsprechenden Header in der für den Reverse-Proxy zuständigen Sektion beispielsweise folgende Konfiguration verwendet werden:
proxy_pass http://127.0.0.1:8080/formcycle/; proxy_set_header Host $http_host; proxy_set_header x-real-ip $remote_addr; proxy_set_header x-forwarded-proto $scheme;
Für Apache Tomcat-Server muss für das Auswerten der mitgesendeten X-Forwarded-Header in der server.xml innerhalb der Catalina-Engine der folgende Valve-Eintrag eingefügt werden:
<Engine...... <Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="<optionale Angabe, siehe unten>" remoteIpHeader="x-forwarded-for" protocolHeader="x-forwarded-proto" protocolHeaderHttpsValue="https" /> </Engine>
Der Default für den Parameter internalProxies ist 10/8, 192.168/16, 169.254/16, 127/8, 172.16/12, and 0:0:0:0:0:0:0:1. Falls die IP(s) des vertrauenswürdigen Proxy-Server nicht damit abgedeckt sind, müssenn diese in Form eines Regulären Ausdrucks angegeben werden. Erwartet wird hier eine oder mehrere IP-Adressen (z.B.: 192\.168\.0\.10|192\.168\.0\.11) oder ein IP-Adressbereich, welcher mittels regulären Ausdrucks (z.B.: 169\.254\.\d{1,3}\.\d{1,3}) definiert werden kann.
Damit die Änderungen in der server.xml des Apache Tomcat-Servers wirksam werden, muss der Dienst neu gestartet werden.
War dieser Artikel hilfreich?
Das ist großartig!
Vielen Dank für das Feedback
Leider konnten wir nicht helfen
Vielen Dank für das Feedback
Feedback gesendet
Wir wissen Ihre Bemühungen zu schätzen und werden versuchen, den Artikel zu korrigieren