Verstecke letzte Bearbeiter
gru 25.5 1 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.
MKO 5.2 2
MKO 16.1 3 {{figure image="proxy_de.jpg"}}
MKO 16.2 4 Manipulation des Hosts und des Protokolls durch einen Revers-Proxy.
MKO 16.1 5 {{/figure}}
MKO 5.2 6
MKO 19.1 7 Der problematische Ablauf (siehe Abbildung) ist hierbei folgender:
MKO 5.2 8
MKO 20.1 9 1. Der Benutzer ruft die URL {{code language="none"}}https://www.example.com/formcycle{{/code}} auf.
MKO 22.1 10 1. Die Anfrage wird vom zwischengeschalteten Server entgegengenommen und interpretiert.
MKO 25.2 11 1. 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 {{code language="none"}}http://192.168.0.1/formcycle{{/code}}. Diese URL kommt nun beim Anwendungsserver an und beinhaltet nicht mehr die benötigten Informationen welche URL vom Benutzer eigentlich aufgerufen wurde.
MKO 17.1 12
13 {{info}}
MKO 31.1 14 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.
MKO 17.1 15 {{/info}}
16
MKO 25.2 17 == Beispielkonfiguration Apache ==
MKO 8.2 18
MKO 28.1 19 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:
MKO 16.1 20
MKO 21.1 21 1. Die Anweisung {{code language="none"}}ProxyPreserveHost On{{/code}} zum Erhalt des ursprünglich aufgerufenen //Host//-Headers
gru 25.7 22 1. 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.
MKO 31.1 23 1. 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).
MKO 21.1 24
MKO 25.2 25 Diese Konfiguration ist, ebenso wie die ggf. nötigen Einstellungen bei der Verwendung selbsterstellter Zertifikate, hier kurz veranschaulicht:
MKO 21.1 26
gru 25.9 27
MKO 19.1 28 {{code language="none"}}
MKO 14.1 29 <VirtualHost www.example.com:80>
MKO 8.2 30 ...
MKO 12.1 31 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
32 ProxyPreserveHost On
MKO 8.2 33 ...
34 # Weiterleitung über HTTP
35 ProxyPass / http://192.168.0.1/
36 ProxyPassReverse / http://192.168.0.1/
MKO 28.1 37 ...
MKO 27.1 38 # Weiterleitung der WebSocket-Verbindung über WS
MKO 28.1 39 RewriteEngine on
MKO 27.1 40 RewriteCond %{HTTP:Upgrade} websocket [NC]
41 RewriteCond %{HTTP:Connection} upgrade [NC]
42 RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L]
MKO 8.2 43 </VirtualHost>
MKO 16.1 44
MKO 12.1 45 <IfModule mod_ssl.c>
46 <VirtualHost www.example.com:443>
MKO 8.2 47 ...
48 SSLEngine on
MKO 12.1 49 SSLProxyEngine On
MKO 8.2 50 ...
51 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
52 ProxyPreserveHost On
MKO 16.1 53
MKO 23.1 54 # Deaktiviert falls nötig die Prüfung des Zertifikats des Anwendungsserver.
MKO 8.2 55 # Nötig falls es sich um selbsterstelle Zertifikate handelt.
56 SSLProxyVerify none
57 SSLProxyCheckPeerCN off
58 SSLProxyCheckPeerName off
59 SSLProxyCheckPeerExpire off
60 ...
61 # Weiterleitung über HTTPS
62 ProxyPass / https://192.168.0.1/
63 ProxyPassReverse / https://192.168.0.1/
MKO 28.1 64 ...
MKO 27.1 65 # Weiterleitung der gesicherten WebSocket-Verbindung über WSS
MKO 28.1 66 RewriteEngine on
MKO 27.1 67 RewriteCond %{HTTP:Upgrade} websocket [NC]
68 RewriteCond %{HTTP:Connection} upgrade [NC]
69 RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L]
MKO 8.2 70 </VirtualHost>
MKO 14.1 71 </IfModule>
72 {{/code}}
gru 25.9 73
gru 25.11 74 == Verwenden von //X-Forwarded// Headern für unverschlüsselte Kommunikation ==
gru 25.9 75
MKO 26.1 76 Wenn der zwischengeschaltete Server das Senden von //X-Forwarded// Headern unterstützt und der {{formcycle/}} hostetende Servlet-Container diese Header auswerten kann, kann die Kommunikation zwischen zwischengeschaltetem Server und {{formcycle/}} auch über ein anderes Protokoll erfolgen. 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.
gru 25.9 77
78 === Konfigurationsbeispiele ===
79
MKO 26.1 80 Im //Apache// kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen //VirtualHost//s beispielsweise wie folgt konfiguriert werden:
gru 25.9 81
82 {{code language="none"}}
MKO 26.1 83 //HTTP
84 RequestHeader set X-Forwarded-Port "80"
85 RequestHeader set X-Forwarded-Proto "http"
86
87 //HTTPS
88 RequestHeader set X-Forwarded-Port "443"
89 RequestHeader set X-Forwarded-Proto "https"
90 {{/code}}
91
92 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:
93
94 {{code language="none"}}
gru 25.9 95 proxy_pass http://127.0.0.1:8080/formcycle/;
96 proxy_set_header Host $http_host;
97 proxy_set_header x-real-ip $remote_addr;
98 proxy_set_header x-forwarded-proto $scheme;
99 {{/code}}
gru 25.10 100
gru 25.9 101 {{velocity}}
102 ##We also have settings for various timeouts in Nginx:
103 ##proxy_connect_timeout 600;
104 ##proxy_send_timeout 600;
105 ##proxy_read_timeout 600;
106 {{/velocity}}
107
gru 25.16 108 Für //Apache Tomcat//-Server muss für das Auswerten der mitgesendeten //X-Forwarded//-Header in der {{code language="none"}}server.xml{{/code}} innerhalb der //Catalina//-Engine der folgende Valve-Eintrag eingefügt werden:
gru 25.9 109
110 {{code language="none"}}
111 <Engine......
112 <Valve className="org.apache.catalina.valves.RemoteIpValve"
113 remoteIpHeader="x-forwarded-for"
114 protocolHeader="x-forwarded-proto"
115 protocolHeaderHttpsValue="https" />
116 </Engine>
117 {{/code}}
Copyright 2000-2024