Change docroot from / to /ui

[lagrianitis]

Hello,

Is it possible to change the docroot of the application from / to /ui (or any) ? I am trying to run it behind load balancer but the app is always calling back the requests to / (even if i rewrite the location in my configuration)

[Lucretius]

Unfortunately, it's not really possible in a one-line change with the way the app is setup. If you wanted to do it manually:

In the App.jsx file, you will see, near the bottom, the route setup as follows:

<Router history={browserHistory}>
      <Route path="/login" component={Login}/>
      <Route path="/" component={Home} onEnter={checkAccessToken}>
          <Route path="*" component={Home}/>
      </Route>
  </Router>

You should be able to just change the "/" path to "/ui" or whatever you want the root to be.

Then, in the Home.jsx file there are many references to / paths which would need to be changed.

This is a single page application, so all routing is handled on the client-side, if that helps any.

[alexunwin]

I am not sure why this is necessary, this is a load balancer config issue. You should be able to specify the root path and it should (for the most part) point to "/". I am not sure I understand the need to change it to "/ui" unless your load balancer is configured for more than one application.

[lagrianitis]

Lucretius thanks for the help that works for my case. Alex my issue wasn't with the application but indeed with the LB

[aaronhurt]

Having a very similar issue. We use path-based routing for nearly all of our backend services and dynamically generate the load balancer config from consul. I'm registering the vault-ui container in consul but noticed that the application wants to use absolute / paths instead of appending the path sent by the load balancer.

[djenriquez]

@leprechau can you post an example of what is going on and the load balancing config that you have if possible? Are you using HAProxy or NGINX?

Vault-UI has successfully been running on many different variations of load-balancing and reverse proxying, even path based routing.

[aaronhurt]

@djenriquez I'm accessing vault-ui from https://domain.foo/vault-ui/ via HAProxy. Example HAProxy config below ...

In main section:

    acl path_vault-ui path_beg /vault-ui/
    use_backend app_vault-ui if path_vault-ui

Backend configuration:

backend app_vault-ui
    mode http
    reqrep ^(GET|PUT|POST|DELETE|PATCH|OPTIONS)\ /vault-ui/(.*) \1\ /\2
    balance roundrobin
    server dkr01.xxx:vault-ui_app_1:8000:nsvltn 1.2.3.4:8000
    server dkr02.xxx:vault-ui_app_1:8000:nsvltn 1.2.3.5:8000
    server dkr03.xxx:vault-ui_app_1:8000:nsvltn 1.2.3.6:8000

The issue is that vault-ui itself loads scripts and resources with absolute paths such as /dist/ that won't work through the load balancer as it is not looking for that path. The application would need to use relative paths for that to work.

[djenriquez]

Thanks for the info @leprechau, we'll take a look. @Lucretius @alexunwin

[andrewl3wis]

I just want to jump in and say that this is still an issue, and I can't get it to run correctly under a prefix

my nginx config looks something like this, and I've tried multiple combinations to try and get it to work:

location /ui/ {
      proxy_pass http://127.0.0.1:8000/;
#      sub_filter "https://vault.prot.sh/" "https://vault.prot.sh/ui/";
#      sub_filter "https://vault.prot.sh/dist/" "https://vault.prot.sh/ui/dist/";
#      sub_filter '<script src="/dist/web-bundle.js"></script>' '<script src="/ui/dist/web-bundle.js"></script>';
#      sub_filter '<link href="/dist/styles.css" rel="stylesheet">' '<link href="/ui/dist/styles.css" rel="stylesheet">';
#      sub_filter_once off;
#      proxy_set_header Accept-Encoding "";
#      sub_filter_types text/html text/css;
     }
     location /dist/ {
     proxy_pass http://127.0.0.1:8000/dist/;
     }

[aaronhurt]

@djenriquez can we get this re-opened?

[djenriquez]

Whoops, sorry guys. I had totally forgotten about this since I dropped the ball on reopening the issue. Doing so now, we'll get to this when we can.

[aaronhurt]

Thank you!

[ShaunBaker]

What is the status of this issue - will it be updated anytime soon?

The change could be as simple as leveraging an environment variable to set the value for the base href HTML tag - and then leverage relative URLs for scripts/styles - thoughts?

@djenriquez

[djenriquez]

Hey @ShaunBaker, probably about time I look into this one eh? I'll take a peek tonight, hopefully it will be that easy. 🤞

[djenriquez]

Hmmm. This is a littler tricker than it should be.

The problem with the current setup is Vault-UI has a backend component, so we can't just apply a variable doc-root with an environment variable since the environment variable only exists on the server-side. In order to get the custom doc-root, we have to tell the Vault-UI client to query the variable from the server. In order to query the variable, we need to know a constant route, since the client does not know what the custom doc-root is until it queries the server.

Then theres the index.html, which defines the location of the assets. In order to have a custom doc-root, we would need the index.html to be aware of that custom doc-root on start. A good way to do this would be parsing a template. However, now we're getting hacky, and hacky is no good.

I'll need to think about this a bit. The community can follow progress here: https://github.com/djenriquez/vault-ui/tree/feature/doc-root. If anyone have any ideas, that would be much appreciated.

On a side note, is hostname based reverse-proxying not an option?

[pvandervelde]

@djenriquez Has there been any progress on this. I'm trying to run VaultUI behind fabio. I'm running VaultUI in a container on port 8000 and fabio is redirecting to http://myfabiohost/dashboards/vault. The page isn't loading because the UI is trying to load the JS files from the root of the URL (i.e. http://myfabiohost)

[djenriquez]

Hi @pvandervelde, it has been sidelined since the obstacle mentioned above was hit. Waiting on creative solutions for this one. This can still be corrected via reverse-proxy that does hostname based routing, its how we do it in my org today.

But, thinking about your use-case that wont work. Maybe we progress the hacky template parsing?