Reverse proxy in subdirectory results in http 500 #34

New Issue

GiteaMirror · 2025-11-07T06:19:35-06:00

GiteaMirror commented

2025-11-07 06:19:35 -06:00

Originally created by @lord-carlos on GitHub (Jul 11, 2018).

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

Originally created by @lord-carlos on GitHub (Jul 11, 2018). 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 :)

GiteaMirror added the question label 2025-11-07 06:19:35 -06:00

GiteaMirror closed this issue

2025-11-07 06:19:35 -06:00

GiteaMirror commented

2025-11-07 06:19:36 -06:00

@mprasil commented on GitHub (Jul 11, 2018):

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.

@mprasil commented on GitHub (Jul 11, 2018): 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](https://serverfault.com/a/379679/164316).

GiteaMirror commented

2025-11-07 06:19:36 -06:00

@dani-garcia commented on GitHub (Jul 11, 2018):

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?

@dani-garcia commented on GitHub (Jul 11, 2018): 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?

GiteaMirror commented

2025-11-07 06:19:37 -06:00

@lord-carlos commented on GitHub (Jul 11, 2018):

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.

@lord-carlos commented on GitHub (Jul 11, 2018): `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.

GiteaMirror commented

2025-11-07 06:19:38 -06:00

@mprasil commented on GitHub (Jul 11, 2018):

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)

@mprasil commented on GitHub (Jul 11, 2018): I wonder if [this](https://github.com/bitwarden/web/issues/215#issuecomment-404309906) 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)

GiteaMirror commented

2025-11-07 06:19:38 -06:00

@lord-carlos commented on GitHub (Jul 16, 2018):

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~

@lord-carlos commented on GitHub (Jul 16, 2018): 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\~

GiteaMirror commented

2025-11-07 06:19:38 -06:00

@mprasil commented on GitHub (Jul 17, 2018):

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.

@mprasil commented on GitHub (Jul 17, 2018): 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.

GiteaMirror commented

2025-11-07 06:19:38 -06:00

@smacz42 commented on GitHub (Feb 19, 2019):

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.

@smacz42 commented on GitHub (Feb 19, 2019): 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.

GiteaMirror commented

2025-11-07 06:19:39 -06:00

@mprasil commented on GitHub (Feb 19, 2019):

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

@mprasil commented on GitHub (Feb 19, 2019): @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.

GiteaMirror commented

2025-11-07 06:19:39 -06:00

@smacz42 commented on GitHub (Apr 4, 2020):

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.

@smacz42 commented on GitHub (Apr 4, 2020): 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.

GiteaMirror commented

2025-11-07 06:19:39 -06:00

@jjlin commented on GitHub (Apr 4, 2020):

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

@jjlin commented on GitHub (Apr 4, 2020): You still need to separately proxy `/notifications/hub` to port 3012 if you want WebSocket notifications to work, though.

GiteaMirror referenced this issue

2025-11-07 07:44:00 -06:00

[PR #34] [MERGED] Implement request guards for organization #2451

GiteaMirror referenced this issue

2026-03-07 19:01:23 -06:00

Protect Organization related GET requests #3649

GiteaMirror referenced this issue

2026-03-07 20:55:09 -06:00

[PR #34] [MERGED] Implement request guards for organization #6228

Sign in to join this conversation.