Proxy reverso do repositório Nexus OSS

Question

Eu tenho um servidor Windows Server 2012-R2 executando Nexus Repository OSS em localhost:8081 . Eu configurei um proxy reverso no IIS com a seguinte regra:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://localhost:8081/{R:1}" />
                </rule>
            </rules>
            <outboundRules>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
    </system.webServer>
</configuration>

Quando acesso o site a partir de outro sistema e navego até nexus.mycompany.com, posso ver o proxy a funcionar ... principalmente. Todos os css, js, etc. dependentes são todos localhost:8081 , o que, é claro, uma máquina remota não pode resolver.

Eu tentei adicionar uma regra de saída esperando que isso corrigisse o problema, mas não o fez.

 <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
                        <match filterByTags="A, Form, Img" pattern="^http(s)?://localhost:8081/(.*)" />
                        <action type="Rewrite" value="http{R:1}://nexus.mycompany.com/{R:2}" />
 </rule>

Olhando para a documentação , tentei definir uma URL base. O botão que ele descreve não está na GUI. Eu encontrei um artigo do Stack Overflow explicando que ele foi movido para a seção Recursos. Eu adicionei o URL base através dos recursos e ainda não funciona.

Eu reiniciei o serviço do Windows após cada alteração.

Eu quero fazer o repositório disponível por meio de um nome de host e fazer com que ele seja carregado adequadamente. Estou faltando alguma coisa óbvia aqui? Existe algum outro motivo para usar URLs completos em vez de URLs relativos?

    

Answer 1

Em uma configuração de proxy reverso, o Nexus procura a presença de vários cabeçalhos X-Forwarded-* HTTP para determinar seu URL base. Contanto que você defina esses cabeçalhos corretamente, ele deve produzir as URLs corretas, sem necessidade de regras de saída.

O truque é saber quais passar - a documentação do proxy reverso não parece particularmente claro sobre o que são, eles apenas oferecem amostras de nginx e Apache sem muita explicação. Eu suspeito que o nginx e o Apache configuram os cabeçalhos necessários automaticamente, e o Nexus os adotou. Isso tudo é um "padrão de fato" em oposição a um padrão formal, portanto, enquanto você vê uma quantidade razoável de consistência na qual os cabeçalhos são suportados pelos aplicativos, isso não é garantido.

Estes são os dois que eu precisava no meu caso:

• X-Forwarded-Host informa ao Nexus o host original solicitado pelo cliente. Isso seria "nexus.mycompany.com" no seu exemplo.
• X-Forwarded-Proto pode ser usado para informar ao Nexus que a solicitação original (ou seja, para o seu proxy) era HTTPS, mesmo que o próprio Nexus não esteja executando HTTPS. Se o seu proxy não for HTTPS, você não precisará disso.

Os cabeçalhos são definidos na seção Variáveis do servidor - substitua os traços por sublinhados e insira um "HTTP_" na frente, portanto X-Forwarded-Host se torna HTTP_X_Forwarded_Host .

Assim, a regra ficaria assim:

<rule name="ReverseProxyInboundRule1" stopProcessing="true">
    <match url="(.*)" />
    <action type="Rewrite" url="http://localhost:8081/{R:1}" />
    <serverVariables>
        <set name="HTTP_X_Forwarded_Proto" value="https" />
        <set name="HTTP_X_Forwarded_Host" value="nexus.mycompany.com" />
    </serverVariables>
</rule>

Novamente, retire o Proto se o seu proxy reverso não for HTTPS.

Com esses cabeçalhos definidos, você não precisará da regra de saída, o que, como você observou, não consegue capturar muita coisa acontecendo nos arquivos JavaScript.

Como um aparte final, você pode considerar deixar esse recurso de URL Base lá - de acordo com os documentos ele é usado para algumas coisas.