UI not working behind reverse proxy

[michael-koeller]

Version: Routinator 0.10.1 Platform: Ubuntu 20.04 Docker image on Debian host

Context: We are running Routinator as a docker container internally for a leading german Telecom provider. In our scenario the Routinator instance is only accessible via a reverse proxy. The proxy also adjusts the exposed URIs:

https://[rev-proxy.company.de]/rpki/routinator/[forwarded-path]

Problem: This common reverse proxy scenario is currently not supported by the UI.

• Request path / triggers a 301 redirect response with Location header field /ui/, which will usually not be rewritten by the reverse proxy, since it's not an absolute URI.
• The UI's HTML markup references its assets in the same way, e.g. <link href="/ui/css/app.css" rel="stylesheet">. The user agents will resolve these references according to RFC 7231 as https://[rev-proxy.company.de]/ui/[asset-path].

In both cases the resulting URI will be denied by the reverse proxy.

Expected:

• Redirect responses (3xx) carry a proper relative or an absulute Location header field value, like: ui/, ../ui/ or http://<origin.server.name>/ui/.
• Relative assets references: <link href="ui/css/app.css" rel="stylesheet">, or <link href="../ui/css/app.css" rel="stylesheet">

[partim]

Sorry for the late reply – we are going to look into the issue and will fix it with the next release.

Minor question: Doesn’t the reverse proxy rewrite the Location header in a 3xx response?

[michael-koeller]

A typical Apachew config snippet will look like this:

  <Location "/rpki/routinator/">
    ProxyPreserveHost on
    ProxyPass        "http://internal.dockerhost.local:8090/"
    ProxyPassReverse "http://internal.dockerhost.local:8090/"
  </Location>

In this case, yes, the Apache server will rewrite any Location response header field.

But only if its value starts with http://internal.dockerhost.local:8090/ (previous HTTP spec revisions required the Location header to carry absolute URIs only, although few people cared) .

Otherwise, the value stays unmodified.

[partim]

Ah! So adding a config parameter for the authority portion of the URI would be a solution here?

[michael-koeller]

It not only the Location header. Resource references within HTML pages also start with a leading "/ui" .

So if a config parameter would fix both cases then yes, that might be a solution.

[partim]

Finally picking this up again – sorry again for the delays.

Using relative references in the UI app turns out tricky. But, an alternative option would be to deploy the UI separately. It can build with a changed base path and Routinator API path. Would that be an option for you?

[michael-koeller]

Hm. At least ti might be a workaround.

With an origin server behind a reverse proxy, you will sometimes want to be able to use both access paths in parallel. Directly to the origin server an via reverse proxy. So in both scenarios the UI should be working.

Deploying the UI with modifying the base path and Routinator API path might allow that. Only if you want to adjust the visible path on the reverse proxy (an infrequent operation), you have to remember to adjust the paths on the origin server accordingly.

However, an important aspect would be that the references in the UI do not contain the origin part of the access URI (https://<host>:<port>), since this would prevent parallel access.

[michael-koeller]

Using relative references in the UI app turns out tricky.

My first impulse was to provide a pull request. But I did not find an easy obvious place where a quick moderate change would be enough. 😉