Customizable "send" URL

[ajgon]

So here is my use-case - I have my whole vaultwarden instance hidden inside my private network. However it would be great, to expose send links (and only them) to the Internet in case I wish to share something with somebody who is not connected to my VPN. Currently send links are just root (/) slashes with some hashtag-javascript-magic, which will require me to expose whole vaultwarden basically.

Would it be possible, to have a configurable "send" path? Or (if it's easier) configurable "send" domain? Currently I have separate domain for "send" and it works like a charm, but I have to manually copy the link every time, replace the main vaultwarden domain with "send" domain, and then send a link which is cumbersome.

Thank you, for this amazing project!

[stefan0xC]

I'm not sure this is possible. First of all, this would have to be done client-side as the generation and handling of Send links is done entirely client-side. So this is not something we control (as we only minimally patch the web-vault to make it compatible with Vaultwarden).

And as far as I've looked into it, this is not configurable for the web-vault either. Bitwarden also just relies on "hashtag-javascript-magic" to redirect send.bitwarden.com links to the proper web-vault (but this approach wouldn't help you if you don't want to expose the web-vault).

[ajgon]

So maybe only configuratble "send" domain? i.e. SEND_DOMAIN=send.example.com and the only place which it needs be used, is where the "send" links are shown/shared to the user? Unless they're also hardcoded in client? Thanks to that, everything else will remain the same.

[stefan0xC]

If you just don't want to manually copy the link, you can look at the bitwarden/clients repository and build the web-vault with the necessary changes as they have done yourself (i.e. that the clients will generate the correct URL)

[ajgon]

But this is the API link, this one is fine (unless I miss something). The thing is, I have two domains pointing to the same vaultwarden instance, let's say vault.example.com and send.example.com. Both work perfectly on their own. The only thing I need, to make this setup to work is vault.example.com generating "share" links for send as send.example.com.

[ajgon]

Nevermind, it occured to me, that this wouldn't make sense, as send.example.com will be also fully exposed, just under different domain 😅

[RealOrangeOne]

It's worth noting that what you see in the browser URL doesn't necessarily correspond to what you'd want to expose. The web vault and API are separate components, and really it's the API you want to isolate. Simply isolating /send isn't going to work as the API isn't accessible at /send.

[ajgon]

Yes, that makes total sense, so we can rule out the "path" option. But what about domain? So vault.example.com generating "share/send" links as https://send.example.com/#/send/......

[ajgon]

Okay, but now I'm exposing whole API under send which is missing the point 😅 . Okay, I think it is what it is then, thanks for clearing this up!

[RealOrangeOne]

https://send.example.com/#/send/.....

That little # in there means it's not actually a path, and it's actually likely your reverse proxy won't even see it.

[stefan0xC]

Shouldn't it work if you only proxy_pass the things the web-vault needs to display Sends and deny everything else? (I mean, the login prompt would be shown but you won't be able to login.)