ProxyPreserveHost scheint wenig für mich zu tun

Ich sehe viele im Web beziehen sich auf die Verwendung von ProxyPreserveHost On, um sicherzustellen, dass ein Proxy-Backend den Hostnamen des ursprünglichen Aufrufers empfängt. Ich verwende dies, um die Sicherheit meiner Webanwendung zu verbessern (Java, Tomcat), während es auch schön wäre, wenn meine Protokolle anzeigen würden, wo sich die Benutzer gerade befinden. Meine Tomcat-Protokolle zeigen das jetzt – ziemlich nutzlos:ProxyPreserveHost scheint wenig für mich zu tun

127.0.0.1 - - [17/Mar/2013:06:32:13 +0100] "GET /webapp/frontend/app/partials/welcome.html HTTP/1.1" 200 54

Dies ist meine Konfiguration, die eindeutig nicht wie erwartet funktioniert:

"/ etc/apache2/sites-enabled/000-default"

<VirtualHost *:80> 
ProxyPreserveHost On 
ProxyPass /webapp http://localhost:8080/webapp 
ProxyPassReverse /webapp http://localhost:8080/webapp 
RewriteEngine On 
RewriteRule ^/$   /webapp/frontend/app/ [proxy] 
RewriteRule ^/webapp/$  /webapp/frontend/app/ [redirect] 
RewriteRule ^/webapp/app/$ /webapp/frontend/app/ [redirect]

(von hier auf Standard-Sachen, die in der 000-default war)

Aktiviert Module:

Dies ist Ubuntu 12.10 mit Apache HTTPD 2.2.22.

Ihre Hilfe würde sehr geschätzt werden.

Quelle

2013-03-17 Sander Verhagen

Ich gehe davon aus, dass Ihr Zugriffsprotokoll weiterhin 127.0.0.1 im Client-Feld enthält. Dies wird nicht von ProxyPreserveHost beeinflusst; Dies ist die IP-Adresse des Netzwerkendpunkts, der mit Apache verbunden ist. Bei Proxyverbindungen von einem anderen Server wird dies immer localhost sein.

Auch ProxyPreserveHost ist über die Erhaltung der Host Header vom Client gesendet, nicht über die ursprüngliche IP des Clients zu bewahren. Mit anderen Worten, es geht darum, dass Informationen für Ihre Zwecke in die falsche Richtung gehen; Es wird der Name des Servers beibehalten, der vom Client gesendet wird, nicht die IP des Clients.

Ich denke, Ihre Frage ist die gleiche wie this question. Ich würde den zusätzlichen Hinweis hinzufügen, dass Sie den X-Forwarded-For Header in Ihren Protokollen unter Verwendung %{X-Forwarded-For}i in Ihrer CustomLog Konfiguration protokollieren können.

Quelle

2013-03-18 00:36:01 rra

Danke. Die Frage, auf die du dich beziehst, hat eine voted-for-Antwort, die auf einen Artikel außerhalb von Stack Overflow verweist, der sich tatsächlich auf "ProxyPreserveHost" als eine Lösung bezieht, so dass der Entwickler nicht mit 'X-Forwarded-For' header enden muss. . Ich bin ein solcher Entwickler, und ich fühlte mich schlecht, etwas Nicht-Standard verwenden zu müssen. Gesagt, ich google 'X-Forwarded-For' und sogar Wikipedia bezeichnet es als einen _de facto_Standard, der viel besser ist als das, was ich ursprünglich dachte (etwas Apache HTTPD-spezifisch, das meine Webanwendung Apache HTTPD-spezifisch macht) . –

Ich denke, dass verlinkte Blogpost nur zum Verwechseln geschrieben wird. Er sagt, dass die Direktive verwendet werden kann, um "den Remote-Host nicht die Remote-IP" zu erhalten. Unter normalen Umständen wären das zwei verschiedene Namen (über DNS) für dasselbe, aber ich denke, dass "der Remote-Host" tatsächlich "den vom Remote-Client gesendeten Host-Header" und nicht den Hostnamen des Remote-Clients meint. Aber tatsächlich, wie geschrieben, ist es ziemlich verwirrend. – rra

Ich ging voran und implementierte eine Überprüfung auf den Rückgabewert von 'HttpServletRequest.getHeader (" X-Forwarded-For ")' zusätzlich zu meiner vorhandenen Prüfung auf 'WebAuthenticationDetails.getRemoteAddress()'. Meine Bewerbung ist somit nun "X-Forwarded-For" bekannt. Nicht das, was ich anfangs erhofft hatte, aber dennoch funktionierte. Vielen Dank. –

ProxyPreserveHost scheint wenig für mich zu tun

Antwort

Verwandte Themen