Solution pour le reverse proxy sur des URL qui ne peuvent pas être déplacées vers un sous-répertoire.

Histoire courte
Gah ! J'aimerais que les développeurs qui ont fait les interfaces d'administration exposent une option "webroot=/myAppAppearsHere", ou rendent tous les liens relatifs.

Longue histoire

J'ai un portail d'administration pour un client qui consiste essentiellement en une connexion apache mod_auth, puis en une série de liens vers des pages d'administration back-end ;

https://portal.mysite.com/login    
https://portal.mysite.com/

et ensuite un tas de liens comme ceci

https://portal.mysite.com/monitoring   -> https://nagios.localdomain/nagios
https://portal.mysite.com/munin     -> https://munin.localdomain/nagios
https://portal.mysite.com/bacukups     -> https://backups.localdomain/backups

Cependant, il y a quelques applications qui n'apprécient pas vraiment d'être envoyées par proxy inverse vers un sous-répertoire, par exemple chef-server-webui et l'interface web de logstash.

ProxyPassReverse remodèlera les en-têtes, mais toutes les URL absolues internes doivent être modifiées et s'il n'y a pas d'option pour cela dans la configuration de l'application, alors il faut les forcer dans la réponse HTML.

La tactique évidente consiste à créer des sous-domaines, ou des sous-domaines génériques, pour les associer à ces applications, comme suit ;

https://chef.mysite.com/   -> https://chefserver.localdomain:4040/
https://logstash.mysite.com/   -> https://logstash.localdomain/
https://*.mysite.com/   -> https://($1).localdomain/

Mais malheureusement je ne contrôle pas l'administration du domaine, et obtenir ces ajouts est possible mais pénible. (mais je préférerais une solution qui ne nécessite pas l'intervention d'une tierce partie pour chaque nouveau lien) (Je suis conscient qu'un joker résoudrait ce problème, mais je suis intéressé de voir quelles sont les alternatives basées sur HTTP et apache ... pour apprendre etc ;-)

J'ai donc décidé d'utiliser le Apache2::ModProxyPerlHtml qui est similaire à mod_proxy_html, et permet le remappage dynamique des chaînes de caractères dans les docs. Cela fonctionne effectivement avec une certaine combinaison de LocationMatch et de ProxyHTMLRewrite, je peux même faire en sorte que le javascript joue bien. Cependant, c'est un véritable casse-tête de faire chacun d'eux, surtout pour les applications qui ne sont pas du web 1.0.

Par exemple, ce qui suit corrige presque logstash pour qu'il fonctionne correctement sous /logstash ;

<LocationMatch "^/logstash/">

    RequestHeader   unset   Accept-Encoding
    PerlSetVar ProxyHTMLVerbose "On"
    PerlInputFilterHandler Apache2::ModProxyPerlHtml
    PerlOutputFilterHandler Apache2::ModProxyPerlHtml
    SetHandler perl-script
    PerlAddVar ProxyHTMLRewrite "/style.css /logstash/style.css"
    PerlAddVar ProxyHTMLRewrite "/css/smoothness/jquery-ui-1.8.5.custom.css /logstash/css/smoothness/jquery-ui-1.8.5.custom.css"
    PerlAddVar ProxyHTMLRewrite "/js/jquery-1.6.1.min.js /logstash/js/jquery-1.6.1.min.js"
    PerlAddVar ProxyHTMLRewrite "action='/search' action='/logstash/search'"
    PerlAddVar ProxyHTMLRewrite "/js/jquery-ui-1.8.13.min.js /logstash/js/jquery-ui-1.8.13.min.js"
    PerlAddVar ProxyHTMLRewrite "/media/throbber.gif /logstash/media/throbber.gif"

    PerlAddVar ProxyHTMLRewrite "/api/search /logstash/api/search"
    PerlAddVar ProxyHTMLRewrite "/api/histogram /logstash/api/histogram"

</LocationMatch>

Mais c'est extrêmement aléatoire, et vous ne pouvez pas simplement remplacer l'URL par une autre, car il y a beaucoup de JSON et de javascript qui sont mélangés.

Je pensais à une sorte de cookie ou de var querystring qui suivrait le backend actuel du proxy, afin qu'Apache puisse rediriger dynamiquement la requête vers le bon backend . Quelque chose comme ça ;

https://admin.mysite.com/?request-proxy=chef -> https://chefserver.localdomain:4040/
https://admin.mysite.com/?request-proxy=logstash  -> https://logstash.localdomain/

En fait, comme Apache a le dernier regard sur tout le contenu HTTP du serveur, il pourrait marquer dynamiquement les urls avec les variables de requête supplémentaires &request-proxy=logstash. Cependant, je pense que cela souffrirait du même problème que la solution ModProxyPerlHtml/mod_proxy_html, à savoir que cela ne fonctionnerait jamais partout, en particulier dans les applications où du javascript est utilisé pour manipuler les paramètres de requête côté client.

J'imagine qu'un cookie pourrait presque fonctionner, dans la mesure où vous pourriez utiliser un proxy basé sur une valeur de cookie passée, par exemple "request-proxy=logstash", mais cela poserait un problème si vous aviez 2 onglets ouverts sur le site, car ils écriraient probablement sur les cookies des autres.

Je sais que certaines applications adoptent une approche de force brute et enveloppent l'ensemble de la requête par procuration dans un code html remanié, comme l'exemple suivant Netscreen SA-3000 .

Quoi qu'il en soit, existe-t-il des modules apache qui mettent en œuvre l'une ou l'autre de ces stratégies, ou qui permettent d'une manière ou d'une autre de contourner l'écriture de règles de correspondance pour chaque site proxy ?

1. ps Je suis au courant de lemonldap, mais je ne suis pas allé bien loin sans avoir à plonger dans le code perl. Bien qu'il semble cool et je vais prendre un autre regard dans le futur.
2. Je commence à penser qu'en termes de temps, je ferais mieux de passer le temps à remapper ces pages HTML avec ModProxyPerlHtml, car il n'y aura pas de solution unique.