Zeige letzte Bearbeiter
1 {{content/}}
2
3 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.
4
5 {{figure image="proxy_de.jpg"}}
6 Manipulation des Hosts und des Protokolls durch einen Revers-Proxy.
7 {{/figure}}
8
9 Der problematische Ablauf (siehe Abbildung) ist hierbei folgender:
10
11 1. Der Benutzer ruft die URL {{code language="none"}}https://www.example.com/formcycle{{/code}} auf.
12 1. Die Anfrage wird vom zwischengeschalteten Server entgegengenommen und interpretiert.
13 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.
14
15 {{info}}
16 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.
17 {{/info}}
18
19 == Beispielkonfiguration Apache ==
20
21 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:
22
23 1. Die Anweisung {{code language="none"}}ProxyPreserveHost On{{/code}} zum Erhalt des ursprünglich aufgerufenen //Host//-Headers
24 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.
25 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).
26
27 Für die Einstellungen am Apache ist es notwendig die entsprechenden Module zu aktivieren. Folgende sind mindestens erforderlich:
28
29 * proxy
30 * proxy_http
31 * proxy_wstunnel
32 * rewrite
33
34 Weiter Informationen zu den Modulen des Apaches finden Sie [[hier>>https://httpd.apache.org/docs/current/mod/||rel="noopener noreferrer" target="_blank"]].
35
36 Die oben erläuterte Konfiguration ist, ebenso wie die ggf. nötigen Einstellungen bei der Verwendung selbsterstellter Zertifikate, hier kurz veranschaulicht:
37
38
39 {{code language="none"}}
40 <VirtualHost www.example.com:80>
41 ...
42 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
43 ProxyPreserveHost On
44 ...
45 # Weiterleitung über HTTP
46 ProxyPass / http://192.168.0.1/
47 ProxyPassReverse / http://192.168.0.1/
48 ...
49 # Weiterleitung der WebSocket-Verbindung über WS
50 RewriteEngine on
51 RewriteCond %{HTTP:Upgrade} websocket [NC]
52 RewriteCond %{HTTP:Connection} upgrade [NC]
53 RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L]
54 </VirtualHost>
55
56 <IfModule mod_ssl.c>
57 <VirtualHost www.example.com:443>
58
59 ...
60 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
61 ProxyPreserveHost On
62 ...
63 SSLEngine on
64 SSLProxyEngine On
65 ...
66 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
67 ProxyPreserveHost On
68
69 # Deaktiviert falls nötig die Prüfung des Zertifikats des Anwendungsserver.
70 # Nötig falls es sich um selbsterstelle Zertifikate handelt.
71 SSLProxyVerify none
72 SSLProxyCheckPeerCN off
73 SSLProxyCheckPeerName off
74 SSLProxyCheckPeerExpire off
75 ...
76 # Weiterleitung über HTTPS
77 ProxyPass / https://192.168.0.1/
78 ProxyPassReverse / https://192.168.0.1/
79 ...
80 # Weiterleitung der gesicherten WebSocket-Verbindung über WSS
81 RewriteEngine on
82 RewriteCond %{HTTP:Upgrade} websocket [NC]
83 RewriteCond %{HTTP:Connection} upgrade [NC]
84 RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L]
85 </VirtualHost>
86 </IfModule>
87 {{/code}}
88
89 == Verwenden von //X-Forwarded// Headern für unverschlüsselte Kommunikation ==
90
91 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//.
92
93 === Konfigurationsbeispiele ===
94
95 Im //Apache// kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen //VirtualHosts// beispielsweise wie folgt konfiguriert werden:
96
97 {{code language="none"}}
98 <VirtualHost www.example.com:80>
99 ...
100 RequestHeader set X-Forwarded-Port "80"
101 RequestHeader set X-Forwarded-Proto "http"
102 ...
103 # Weiterleitung über HTTP
104 ProxyPass / http://192.168.0.1/
105 ProxyPassReverse / http://192.168.0.1/
106 ...
107 # Weiterleitung der WebSocket-Verbindung über WS
108 RewriteEngine on
109 RewriteCond %{HTTP:Upgrade} websocket [NC]
110 RewriteCond %{HTTP:Connection} upgrade [NC]
111 RewriteRule ^/?(.*) "ws://192.168.0.1:80/$1" [P,L]
112 </VirtualHost>
113
114 <IfModule mod_ssl.c>
115 <VirtualHost www.example.com:443>
116 ...
117 # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
118 ProxyPreserveHost On
119 ...
120 SSLEngine on
121 SSLProxyEngine On
122 ...
123 RequestHeader set X-Forwarded-Port "443"
124 RequestHeader set X-Forwarded-Proto "https"
125 ...
126 # Weiterleitung über HTTPS
127 ProxyPass / http://192.168.0.1/
128 ProxyPassReverse / http://192.168.0.1/
129 ...
130 # Weiterleitung der gesicherten WebSocket-Verbindung über WSS
131 RewriteEngine on
132 RewriteCond %{HTTP:Upgrade} websocket [NC]
133 RewriteCond %{HTTP:Connection} upgrade [NC]
134 RewriteRule ^/?(.*) "wss://192.168.0.1:443/$1" [P,L]
135 </VirtualHost>
136 </IfModule>
137 {{/code}}
138
139 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:
140
141 {{code language="none"}}
142 proxy_pass http://127.0.0.1:8080/formcycle/;
143 proxy_set_header Host $http_host;
144 proxy_set_header x-real-ip $remote_addr;
145 proxy_set_header x-forwarded-proto $scheme;
146 {{/code}}
147
148 {{velocity}}
149 ##We also have settings for various timeouts in Nginx:
150 ##proxy_connect_timeout 600;
151 ##proxy_send_timeout 600;
152 ##proxy_read_timeout 600;
153 {{/velocity}}
154
155 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:
156
157 {{code language="none"}}
158 <Engine......
159 <Valve className="org.apache.catalina.valves.RemoteIpValve"
160 internalProxies="<optionale Angabe, siehe unten>"
161 remoteIpHeader="x-forwarded-for"
162 protocolHeader="x-forwarded-proto"
163 protocolHeaderHttpsValue="https" />
164 </Engine>
165 {{/code}}
166
167 Der Default für den Parameter [[//internalProxies //>>https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/filters/RemoteIpFilter.html||rel="noopener noreferrer" target="_blank"]]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.