No problem. I will take this up with the Tomcat folks. Thanks for your time.

Andrew

I am sorry but I didn’t have the time to work on this as I would have liked and I will not have the time during the next months.

Can you continue this discussion on the tomcat-users mailing list as the RemoteIpValve is now a mature part of Tomcat.

I hope you will find people interested in developing such extension.

Cyrille

Apologies for the English!

Back in November 2010 we had a discussion about an enhancement to the Tomcat RemoteIpValve (http://www.coderanch.com/t/445496/Tomcat/request-getRemoteAddr). It went like this:
=========================================================================

Andrew Swanson wrote:
I am using the RemoteIpValve to correctly set request.isSecure and request.scheme but I am using the « ProxyPreserveHost » Apache httpd directive so that request.serverHost and request.serverPort are correctly set in Tomcat. Is there anyway to prevent RemoteIpValve from populating the request.serverPort when it detects the presence of the $protocolHeader http header?

Cyrille Le Clerc wrote:Hello Andrew,

You are right, RemoteIpValve (and RemoteIpFilter) currently override the serverPort when you specify a protocol header (e.g. x-forwarded-proto). Would you like to add a boolean configuration option override-http-server-port-with-protocol-information to disable this behavior for your use case ?

Thanks for your interest in RemoteIpValve,

Cyrille

Andrew Swanson wrote:
Yes, something like that would be most helpful.
=========================================================================

Has this change made it into Tomcat? If so, what version? If not, are there any plans to add it?

Thanks for your time.

Andrew Swanson
Caterpillar Inc.

Merci encore, la correction est appliquée : Commit 890483 : Make configuration attributes consistent between Filter and Valves, le paramètre de configuration s’appelle désormais protocolHeaderHttpsValue.

Cyrille (Xebia)

Ce sera Bug 48387 – Make RemoteIpFilter parameters consistent with RemoteIpValve.

Cyrille (Xebia)

La JavaDoc dit :
protocolHeaderHttpsValue: Value of the protocolHeader to indicate that it is an Https request

Le code source dit autre chose :
protected static final String PROTOCOL_HEADER_SSL_VALUE_PARAMETER = « protocolHeaderSslValue »;

Quoi qu’il en soit, merci pour le code de ce filter, il m’est bien utile.

Je trouve amusant que Squid ait été l’inventeur du header X-Forwarded-For et qu’en revanche, ils aient oublié le header X-Forwarded-Proto au point ne ne pas le voir et d’intégrer son équivalent FRONT_END_HTTPS utilisé par Microsoft Outlook Web Access (OWA) .

Cyrille (Xebia)

Par contre, la solution est d’ajouter au niveau du cache_peer la directive front-end-https :

cache_peer localhost parent 8080 0 no-query originserver login=PASS name=tomcat_peer front-end-https=auto

Cela aura pour effet d’ajouter un header
FRONT_END_HTTPS = On
si la requete est en https coté squid, et pas de header dans le cas http.

Il ne reste plus qu’a adapter ensuite le XForwardedFilter ou bien la configuration du serveur Java pour prendre en compte ce header au lieu de X-Forwarded-Proto.

Nous sommes d’accord. lorsqu’un serveur Apache Httpd est en amont du serveur Tomcat, on peut se permettre de faire écouter le serveur Tomcat sur des ports supérieurs à 1024 (e.g. 8080) ; il n’y a alors pas de problème d’écoute sur les ports 80 et 443 qui requièrent de s’exécuter en root.

Notre point porte sur un serveur Tomcat seul, sans Apache Httpd en frontal. Faire écouter un serveur sur les ports <1024 comme 80 et 443 requiert de démarrer le processus en root. Cependant, à la différence d’Apache Httpd qui sait changer de user après son démarrage en root pour restreindre ses privilèges, une JVM (Tomcat mais également Glassfish, JBoss, WebSphere, Weblogic, etc) ne sait pas changer de user et devrait donc s’exécuter en root.
Comme il est le plus souvent incompatible avec les règles de sécurité de s’exécuter en root, nous avons proposé l’astuce iptables.

Cyrille (Xebia)

Il est aussi possible avec httpd.conf de faire un alias/forward de 8080 vers 80.