Solução para Proxy Reverso em URLs que não são passíveis de serem relocadas para um subdiretório

Question

História curta
Gah! Desejo que os desenvolvedores que fizeram interfaces administrativas exponham uma opção "webroot = / myAppAppearsHere" ou tornem todos os links relativos.

Longa história

Eu tenho um portal de administração para um cliente que é basicamente um login do mod_auth do apache e, em seguida, uma série de links para páginas de administração de back-end da mesma forma;

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

e, em seguida, um monte de links, como assim

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

No entanto, existem algumas aplicações que não estão muito satisfeitas com o proxy invertido para um subdiretório, por exemplo, chef-server-webui e a interface web logstash.

O ProxyPassReverse irá remapear os cabeçalhos, mas todas as URLs absolutas internas precisam ser alteradas e, se não houver uma opção para isso na configuração do aplicativo, isso deve ser coagido na resposta HTML.

A tática óbvia é criar subdomínios ou subdomínios curinga para mapear esses aplicativos da seguinte forma:

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

Mas infelizmente eu não estou no controle da administração do domínio, e obter essas adições é possível, mas uma dor. (mas eu preferiria uma solução que não exigisse envolvimento de terceiros para cada novo link) (estou ciente de que um curinga resolveria isso, mas estou interessado em ver quais alternativas baseadas em HTTP e apache existem. .. para aprender etc; -)

Por isso, mudei-me para usar o Apache2 :: ModProxyPerlHtml , que é semelhante ao mod_proxy_html, e permite a dinâmica remapeamento de strings nos docs. Isso realmente funciona com alguma combinação de LocationMatch e ProxyHTMLRewrite eu posso até obter o javascript para jogar legal. No entanto, é uma enorme dor de saco para cada um, especialmente para qualquer aplicativo que não seja da web 1.0.

Por exemplo, o seguinte quase corrige o logstash para funcionar corretamente em / 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>

Mas é extremamente imprevisível, e você não pode simplesmente curvar a troca de URL, porque há um monte de JSON e javascript que são desconfigurados.

Eu estava pensando em algum tipo de cookie ou querystring var que rastreou o atual back-end de proxy, para que o apache pudesse redirecionar dinamicamente a solicitação para o back-end correto. Algo parecido com isto;

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

E, basicamente, quando o apache obtém a última análise de todo o conteúdo HTTP do servidor, ele pode codificar dinamicamente URLs com as consultas adicionais vars & request-proxy = logstash. No entanto, estou pensando que sofreria do mesmo problema que a solução ModProxyPerlHtml / mod_proxy_html, pois nunca funcionaria em todos os lugares, especialmente em aplicativos em que algum javascript era usado para interagir com o lado do cliente QUERY params.

Eu acho que um cookie quase funcionaria, em que você poderia Proxy com base em algum valor de cookie passado dizer "request-proxy = logstash", no entanto, isso sofreria um problema se você tivesse 2 guias abertas para o site como provavelmente escrever sobre os cookies uns dos outros.

Eu sei que alguns aplicativos apenas adotam algum tipo de abordagem de força bruta e envolvem toda a solicitação de proxy no html re-cozido, como o Netscreen SA-3000 .

De qualquer forma, existem módulos apache que implementam essas estratégias ou, de alguma forma, escrevem regras correspondentes para cada site com proxy.?

1. ps Eu estou ciente de lemonldap, mas eu não fui longe sem ter que mergulhe no código perl. Embora pareça legal e eu vou tomar outro olhar no futuro.
2. Estou começando a suspeitar que, no tempo, eu poderia simplesmente gastar o tempo remapeando essas páginas HTML com ModProxyPerlHtml, porque não haveria uma solução única para todos os tipos.

Answer 1

mod_substitute faz o trabalho muito bem;

Summary: mod_substitute provides a mechanism to perform both regular expression and fixed string substitutions on response bodies.

Leva um pouco de tempo trabalhando nas regras de mapeamento.