Outdated Documentation for Apache in Sublocation Config

[vollkorn1982]

Subject of the issue

The documentation explains a deprecated setup for the websocket.

Steps to reproduce

According to https://github.com/dani-garcia/vaultwarden/releases/tag/1.30.0 the websocket setup on port 3012 is deprecated.
The section "Apache in a sub-location (by ss89)" on https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples still shows an example setup with the deprecated setup for a websocket on port 3012:

        RewriteCond %{HTTP:Upgrade} =websocket [NC]
        RewriteRule /notifications/hub(.*) ws://<SERVER>:3012/$1 [P,L]
        ProxyPass http://<SERVER>:80/$sublocation/

Expected behaviour

The documentation on Apache with a sublocation reflects the currently supported setup mode.

[BlackDex]

It's a wiki, if you know how it should be please help us update it.

[vollkorn1982]

@agentdr8 I am confused by your config. Isn't it redirecting to a sublocation on the internal server behind the apache reverse proxy as well? To like 127.0.0.1:8000/sublocation/ ?

That's not what I understood the intent of the config to be. I thought it was supposed to redirect from a reverse proxy address domain/sublocation to an internal address like 127.0.0.1:8000, without any further sublocation. At least I would expect to use different variables for the external sublocation on the reverse proxy and the internal sublocation, which will rarely be set to the same value.

[agentdr8]

The $sublocation variable was taken from the previous example config. I don't think it actually gets substituted from anything -- and the reason I posted it was because I also defined the Domain path (base dir) within Vaultwarden config, so it needs to exist in the RewriteRule too. See this link for more details.

[vollkorn1982]

Interesting. This is totally not how I expected this to work. Why is vaultwarden generally configured to locally use the subdir as well? I configured my apache like this now:

<Location /bitwarden>
    ProxyPass http://127.0.0.1:8000/ upgrade=websocket

    ProxyPreserveHost On
    RequestHeader set X-Real-IP %{REMOTE_ADDR}s
</Location>

This seems works fine (tested on the webfrontend) and it seems a cleaner solution to me. What am I not understanding here?

[agentdr8]

If I had to wager a guess, it would be that VW determines the base dir from the domain that you enter for your VW site, and uses that to build proper API routes and links found throughout the web vault. If your reverse proxy is then stripping the base dir from requests it forwards on, those WS/WSS endpoints won't exist. I'd be surprised if you weren't seeing WS errors in your dev console, unless your VW domain does not include your base dir.

Back in the Bitwarden_RS days, the base dir was a separate config item from the domain in the .env, but now it appears to not need the base dir separately defined.

Also, IIRC, the old websocket server on 3012 did not take the base dir into account, which is why you would just pass the path on without the base dir.

[jjlin]

Vaultwarden needs to know the base dir because it sometimes generates URLs in its responses (e.g., URL that the client should use to download an attachment). If you configure Vaultwarden without the base dir and just have the reverse proxy strip the base dir from the path passed to Vaultwarden, then most things will probably work fine, but some things (like attachments) will break mysteriously.