1

I have a Windows Server 2012-R2 Server running Nexus Repository OSS on localhost:8081. I configured a Reverse Proxy in IIS with the following rule:

<?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>

When I access the site from another system and navigate to nexus.mycompany.com I can see the proxy working... mostly. All the dependent css, js, etc are all localhost:8081 which of course, a remote machine cannot resolve.

I tried adding an outbound rule hoping it would fix the issue, it did not.

 <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>

Looking at the documentation, I tried setting a base URL. The button it describes isn't in the GUI. I found a Stack Overflow article explaining that it's been moved to the Capabilities section. I added the base url through the capabilities, and it still doesn't work.

I have restarted the windows service after each change.

I want to do is have the repository available via a hostname and have it load appropriately. Am I missing something obvious here? Is there some other reason why it's using full URLs instead of relative URLs?

blur0224
  • 128
  • 1
  • 10

1 Answers1

3

In a reverse proxy setup, Nexus looks for the presence of various X-Forwarded-* HTTP headers in order to determine its base URL. As long as you set these headers correctly, it should produce the correct URLs, no outbound rules needed.

The trick is to know which ones to pass -- the reverse proxy documentation doesn't seem particularly clear about what those are, they just offer up nginx and Apache samples without much explanation. I suspect nginx and Apache set the necessary headers automatically, and Nexus has adopted those. This is all a "de facto standard" as opposed to a formal one, so while you see a fair amount of consistency in which headers are supported across applications, it's not guaranteed.

These are the two I needed in my case:

  • X-Forwarded-Host tells Nexus the original host requested by the client. This would be "nexus.mycompany.com" in your example.
  • X-Forwarded-Proto can be used to tell Nexus that the original request (i.e. to your proxy) was HTTPS, even if Nexus itself isn't running HTTPS. If your proxy isn't HTTPS, then you shouldn't need this.

Headers are set in the Server Variables section -- replace dashes with underscores and slap an "HTTP_" on the front, so X-Forwarded-Host becomes HTTP_X_Forwarded_Host.

So the rule would end up looking like this:

<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>

Again, take out the Proto one if your reverse proxy isn't HTTPS.

With those headers set, you shouldn't need the outbound rule, which as you noted isn't able to catch a lot of the stuff happening in the Javascript files.

As a final aside, you may want to consider leaving that Base URL capability in there -- according to the docs it does get used for a few things.

Mike Paxton
  • 46
  • 2