Reverse proxy in subdirectory results in http 500

[lord-carlos]

Hallo

Is it possible to run bitwarden_rs behind a reverse proxy in a subdirectoy?
Like mydomain.tld/bitwarden?

If I try I get errors:

GET /bitwarden text/html:
=> Matched: GET /<p..>
=> Error: Response was a non-Responder Err: Os { code: 2, kind: NotFound, message: "No such file or directory" }

Because rocket things I want to access /bitwarden.
From other services I'm used to set a http header to let the application know. Something possible here?

Thanks for reading :)

[mprasil]

Can you perhaps share relevant part of your proxy configuration? It should definitely be possible with the API, I'm not 100% sure about the Valut interface and client apps, but I think it should work as well. (as long as you set proper API URL in the client) You might just need to rewrite the URL on the proxy side. Here's how you can do that with nginx.

[dani-garcia]

The Rocket web server doesn't allow to change the server root directory, at least without modifiyng the code.

I also remember seeing somewhere that the web vault is hardcoded to the root directory. So there is a chance that it's not going to work, even with the URL rewriting.

The easiest way would be to run the instance under a subdomain, like bitwarden.mydomain.tld. Is that an option to you?

[lord-carlos]

rewrite /bitwarden/(.*) /$1 break; starts a new can of worms. The index page works, but it tries to get js/settings.js from the root again. I can add some rules for that.

subs_filter_types text/javascript;
subs_filter 'js/' 'bitwarden/js/' g;
subs_filter 'lib/' 'bitwarden/lib/' g;
subs_filter 'css/' 'bitwarden/css/' g;

But then other stuff fails. (bootstrap, agular etc.) Not sure how to rewrite that.

@dani-garcia
I'm already on a subdomain, as I only got a dyndns for my homeserver. Not sure if lets encrypt supports sub sub domains? Anyhow, then I have to do stuff with lets encrypt again. Might just directly open bitwarden to the outside on another port.

[mprasil]

I wonder if this won't fix your issue with Vault and rewrite?

Have you tried to configure Android or some other client with the API in the subdirectory? (and with rewrite in place)

[lord-carlos]

Hi and thanks for the quick replays.

No, I have not tested the API yet.
href="" might do it. But that's not going to help me with bitwarden_rs I assume? Or make a rewrite for it? Could not make it work, but will take a look at it when I get the time. Else I will just have to use another port ;-) Or use ~the cloud~

[mprasil]

I think the only problem with this is that the clients expect the API to be at certain path. The above linked issue will only (maybe) resolve the problem with vault, but if any other apps expect the API to be present at /api there's nothing we can do on our side unfortunately.

I'm going to close this now as we established, that you can rewrite the URL on the proxy side so there's not much else we need to do here. It probably still won't work but that's due to client-side restriction. Feel free to reopen or create new issue if you think there's anything we can do.

[smacz42]

As long as the subdirectories are proxied to the server, it seems to work. I have no other service that makes calls on /api, so I forwarded those (as well as /identity) to the bitwarden instance.

For instance, here is the relevant bits of my nginx config after trying it out a bit and tailing the log to find which calls were being generated:

location /bitwarden/ {
    proxy_headers_hash_max_size 512;
    proxy_headers_hash_bucket_size 64;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    add_header Front-End-Https on;
    proxy_pass http://bitwarden/;
  }

  location /notifications/hub {
    proxy_pass http://bitwarden:3012;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  location /notifications/hub/negotiate {
    proxy_pass http://bitwarden;
  }

  location /api {
    proxy_pass http://bitwarden;
  }

  location /identity {
    proxy_pass http://bitwarden;
  }

Preliminary testing of creating an account, logging in, creating a new entry, and retrieving that entry with both the Android and web clients was successful. I'd be interested if the devs know of any other functionality that would be worthwhile to test.

[mprasil]

@smacz42, I think this is interesting middle ground where the API itself is still exposed on /api where Vault is expecting it while having the rest of the service (like the Vault files or admin) in sub-url. I guess that would be a solution for a lot of people that want to have different applications on the same domain as long as no other application needs /api for its own functionality.

[smacz42]

FWIW, after upgrading to 1.14.X the workaround above is no longer necessary. The web application correctly redirects all of the base urls (/api, /identity, /notifications) correctly. All that is necessary is the first location block.

[jjlin]

You still need to separately proxy /notifications/hub to port 3012 if you want WebSocket notifications to work, though.