search

linuxserver / reverse-proxy-confs

These confs are pulled into our SWAG image: https://github.com/linuxserver/docker-swag
GNU General Public License v3.0
1.33k stars 300 forks source link

[BUG] Vaultwarden reverse proxy change #623

Closed Mat-DB closed 9 months ago

Mat-DB commented 9 months ago

Is there an existing issue for this?

Current Behavior

The vaultwarden project has updated recently and the reverse proxy should change.

More info here

I have no idea someone already know this or not so I just let you know.

Kind regards, Matthias

Expected Behavior

No response

Steps To Reproduce

-

aptalca commented 9 months ago

Thanks. We're aware

Mat-DB commented 9 months ago

I know a little about nginx but I always want to learn. Why is the config here still different then the example config on the vautlwarden wiki page? More specific why are the following sections in the config?

Thanks!

nemchik commented 9 months ago

I know a little about nginx but I always want to learn. Why is the config here still different then the example config on the vautlwarden wiki page? More specific why are the following sections in the config?

  • location ~ (/vaultwarden)?/api
  • location ~ (/vaultwarden)?/notifications/hub

Thanks!

Our configs all include commented lines that (when uncommented) grant you the ability to add an auth layer such as authentik or authelia (or others if you write the confs yourself). With either of those enabled, you would want the main web UI of any given app to be protected by the auth configs, but you would not want things like API or websockets (often used for client applications rather than web browsers to connect to the application) to be protected by the auth configs being enabled in your proxy. In this specific case, the api and notification hub endpoints are things used by clients (such as the bitwarden app or browser extension) and not necessarily by the web UI (although I think they might be used there too). The clients don't have a way to authenticate with any custom auth proxy confs (like authentik/authelia) or even to know about them, and they would just report an error in trying to connect to vaultwarden/bitwarden, so we include these endpoints to allow bypassing additional auth and just use whatever auth the application (vaultwarden) has in place for those endpoints. As to why the VW wiki page does not have these same configurations, they likely don't have a need to account for additional auth configurations.

Mat-DB commented 9 months ago

Thank you for the explanation!! Now I understand, makes sense.