Wiki-Quellcode von Betrieb hinter Proxy/Load-Balancer o.ä.

Verstecke letzte Bearbeiter

version	line-number	content
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.
5.2	2
16.1	3	{{figure image="proxy_de.jpg"}}
16.2	4	Manipulation des Hosts und des Protokolls durch einen Revers-Proxy.
16.1	5	{{/figure}}
5.2	6
19.1	7	Der problematische Ablauf (siehe Abbildung) ist hierbei folgender:
5.2	8
20.1	9	1. Der Benutzer ruft die URL {{code language="none"}}https://www.example.com/formcycle{{/code}} auf.
22.1	10	1. Die Anfrage wird vom zwischengeschalteten Server entgegengenommen und interpretiert.
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.
17.1	12
	13	{{info}}
25.12	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. Alternativ muss der zwischengeschaltete Server über //X-Forwarded// Header mitteilen, welches Protokoll die Anfrage ursprünglich verwendet hat.
17.1	15	{{/info}}
	16
25.2	17	== Beispielkonfiguration Apache ==
8.2	18
25.2	19	Für die korrekte Konfiguration eines Apache-Server, welcher als Revers-Proxy agiert, sind zwei Punkte relevant und z.B. in der Konfiguration der VirtualHost´s zu hinterlegen:
16.1	20
21.1	21	1. Die Anweisung {{code language="none"}}ProxyPreserveHost On{{/code}} zum Erhalt des ursprünglich aufgerufenen //Host//-Headers
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.
21.1	23
25.2	24	Diese Konfiguration ist, ebenso wie die ggf. nötigen Einstellungen bei der Verwendung selbsterstellter Zertifikate, hier kurz veranschaulicht:
21.1	25
25.9	26
19.1	27	{{code language="none"}}
14.1	28	<VirtualHost www.example.com:80>
8.2	29	...
12.1	30	# Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
	31	ProxyPreserveHost On
8.2	32	...
	33	# Weiterleitung über HTTP
	34	ProxyPass / http://192.168.0.1/
	35	ProxyPassReverse / http://192.168.0.1/
	36	</VirtualHost>
16.1	37
12.1	38	<IfModule mod_ssl.c>
	39	<VirtualHost www.example.com:443>
8.2	40	...
	41	SSLEngine on
12.1	42	SSLProxyEngine On
8.2	43	...
	44	# Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver.
	45	ProxyPreserveHost On
16.1	46
23.1	47	# Deaktiviert falls nötig die Prüfung des Zertifikats des Anwendungsserver.
8.2	48	# Nötig falls es sich um selbsterstelle Zertifikate handelt.
	49	SSLProxyVerify none
	50	SSLProxyCheckPeerCN off
	51	SSLProxyCheckPeerName off
	52	SSLProxyCheckPeerExpire off
	53	...
	54	# Weiterleitung über HTTPS
	55	ProxyPass / https://192.168.0.1/
	56	ProxyPassReverse / https://192.168.0.1/
	57	</VirtualHost>
14.1	58	</IfModule>
	59	{{/code}}
25.9	60
25.11	61	== Verwenden von //X-Forwarded// Headern für unverschlüsselte Kommunikation ==
25.9	62
25.15	63	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.
25.9	64
	65	=== Konfigurationsbeispiele ===
	66
25.14	67	Bei //nginx// kann für das Mitsenden der entsprechenden Header in der für den Reverse-Proxy zuständigen Sektion beispielsweise beispielsweise folgende Konfiguration verwendet werden:
25.9	68
	69	{{code language="none"}}
	70	proxy_pass http://127.0.0.1:8080/formcycle/;
	71	proxy_set_header Host $http_host;
	72	proxy_set_header x-real-ip $remote_addr;
	73	proxy_set_header x-forwarded-proto $scheme;
	74	{{/code}}
25.10	75
25.9	76	{{velocity}}
	77	##We also have settings for various timeouts in Nginx:
	78	##proxy_connect_timeout 600;
	79	##proxy_send_timeout 600;
	80	##proxy_read_timeout 600;
	81	{{/velocity}}
	82
25.16	83	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:
25.9	84
	85	{{code language="none"}}
	86	<Engine......
	87	<Valve className="org.apache.catalina.valves.RemoteIpValve"
	88	remoteIpHeader="x-forwarded-for"
	89	protocolHeader="x-forwarded-proto"
	90	protocolHeaderHttpsValue="https" />
	91	</Engine>
	92	{{/code}}

Wiki-Quellcode von Betrieb hinter Proxy/Load-Balancer o.ä.

Navigation