| ... |
... |
@@ -55,11 +55,7 @@ |
| 55 |
55 |
|
| 56 |
56 |
<IfModule mod_ssl.c> |
| 57 |
57 |
<VirtualHost www.example.com:443> |
| 58 |
|
- |
| 59 |
59 |
... |
| 60 |
|
- # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver. |
| 61 |
|
- ProxyPreserveHost On |
| 62 |
|
- ... |
| 63 |
63 |
SSLEngine on |
| 64 |
64 |
SSLProxyEngine On |
| 65 |
65 |
... |
| ... |
... |
@@ -88,11 +88,11 @@ |
| 88 |
88 |
|
| 89 |
89 |
== Verwenden von //X-Forwarded// Headern für unverschlüsselte Kommunikation == |
| 90 |
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//. |
|
87 |
+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. |
| 92 |
92 |
|
| 93 |
93 |
=== Konfigurationsbeispiele === |
| 94 |
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: |
|
91 |
+Im //Apache// kann das Mitsenden der entsprechenden Header in den für den Reverse-Proxy zuständigen //VirtualHost//s beispielsweise wie folgt konfiguriert werden: |
| 96 |
96 |
|
| 97 |
97 |
{{code language="none"}} |
| 98 |
98 |
<VirtualHost www.example.com:80> |
| ... |
... |
@@ -114,9 +114,6 @@ |
| 114 |
114 |
<IfModule mod_ssl.c> |
| 115 |
115 |
<VirtualHost www.example.com:443> |
| 116 |
116 |
... |
| 117 |
|
- # Aktiviert das Erhalten des ursprünglich aufgerufenen Hosts bis zum Anwendungsserver. |
| 118 |
|
- ProxyPreserveHost On |
| 119 |
|
- ... |
| 120 |
120 |
SSLEngine on |
| 121 |
121 |
SSLProxyEngine On |
| 122 |
122 |
... |
| ... |
... |
@@ -164,4 +164,4 @@ |
| 164 |
164 |
</Engine> |
| 165 |
165 |
{{/code}} |
| 166 |
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. |
|
160 |
+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. |
