Betrieb hinter Proxy/Load-Balancer o.ä.

author	version	line-number	content
1	Sollte der Anwendungsserver (z.B. Tomcat) auf welchem {{formcycle/}} installiert ist hinter einem weiteren Server z.B. einem Revers-Proxy, einem Load-Bancer 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 zwischengeschaltenen Server entgegengenommen werden und als neue Anfrage an den Andwendungs-Server gestellt werden. In Abbildung XYZ ist dieser Ablauf wie folgt zu erkennen:
2
3	1. Der Benutzer ruft die URL https://www.example.com/formcycle auf.
4	1. Die Anfrage wird vom zwischengeschaltenen Server entgegengenommen und interpretiert.
5	1. Der zwischengeschaltene Server reicht 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.
6
7	{{figure image="proxy_de.jpg"}}
8	Manipulation des Hosts und des Protokolls durch einen Revers-Proxy.
9	{{/figure}}
10
11
12	Da {{formcycle/}} jedoch vor allem bei der Anmeldung an einem Formular die ursprünge Aufruf-URL des Benutzers benötigt und diese somit nicht korrekt ermittelt werden kann, ist es nötig die zwischengeschaltenen Server so zu konfigurieren, dass es zu keiner Änderung der Aufruf-URL kommt. Hierbei ist darauf zu achten, dass sowohl der HTTP-Header "Host" als auch das verwendete Protokoll (HTTP oder HTTPS) unverändert weitergereicht werden.
13
14	== Beispiel Apache Proxy ==
15
16
17	(((
18	{{code}}
19	<VirtualHost www.example.com:80>
20	...
21	# Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
22	ProxyPreserveHost On
23	...
24	# Weiterleitung über HTTP
25	ProxyPass / http://192.168.0.1/
26	ProxyPassReverse / http://192.168.0.1/
27	</VirtualHost>
28
29	<IfModule mod_ssl.c>
30	<VirtualHost www.example.com:443>
31	...
32	SSLEngine on
33	SSLProxyEngine On
34	...
35	# Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
36	ProxyPreserveHost On
37
38	# Deaktivert falls nötig die Prüfung des Zertifikats des Anwendungsserver.
39	# Nötig falls es sich um selbsterstelle Zertifikate handelt.
40	SSLProxyVerify none
41	SSLProxyCheckPeerCN off
42	SSLProxyCheckPeerName off
43	SSLProxyCheckPeerExpire off
44	...
45	# Weiterleitung über HTTPS
46	ProxyPass / https://192.168.0.1/
47	ProxyPassReverse / https://192.168.0.1/
48	</VirtualHost>
49	</IfModule>
50	{{/code}}
51	)))

1

Sollte der Anwendungsserver (z.B. Tomcat) auf welchem {{formcycle/}} installiert ist hinter einem weiteren Server z.B. einem Revers-Proxy, einem Load-Bancer 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 zwischengeschaltenen Server entgegengenommen werden und als neue Anfrage an den Andwendungs-Server gestellt werden. In Abbildung XYZ ist dieser Ablauf wie folgt zu erkennen:

2

3

1. Der Benutzer ruft die URL https://www.example.com/formcycle auf.

4

1. Die Anfrage wird vom zwischengeschaltenen Server entgegengenommen und interpretiert.

5

1. Der zwischengeschaltene Server reicht 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.

6

7

8

Manipulation des Hosts und des Protokolls durch einen Revers-Proxy.

Da {{formcycle/}} jedoch vor allem bei der Anmeldung an einem Formular die ursprünge Aufruf-URL des Benutzers benötigt und diese somit nicht korrekt ermittelt werden kann, ist es nötig die zwischengeschaltenen Server so zu konfigurieren, dass es zu keiner Änderung der Aufruf-URL kommt. Hierbei ist darauf zu achten, dass sowohl der HTTP-Header "Host" als auch das verwendete Protokoll (HTTP oder HTTPS) unverändert weitergereicht werden.

13

14

== Beispiel Apache Proxy ==

(((

...