Okay so this might be a bit difficult to figure out since I’m completely lost as to why it isn’t working. I’m trying to download attachments from bitwarden in Firefox and for some reason the file I receive just contains the word “null” instead of whatever was in the file I uploaded. I’m not sure if it’s related to https://github.com/dani-garcia/bitwarden_rs/issues/921 as well, but I figure it might.
Here’s a small gif illustrating what I’m doing when encountering this issue
Essentially, I’ll upload an attachment to bitwarden and when I download it again in Firefox (or the bitwarden extension on my Firefox browser), the content of this file is just “null”. But I’m sure it was uploaded correctly because if I try to download the attachment from my android phone or chromium, I can see the expected content of the file. I’ve looked at the bitwarden_rs docker container logs and nothing seems to indicate anything wrong. The request looks normal, but I could be missing something here. I’m just not sure where to look at this point. Perhaps the issue is with the front-end / extensions? In which case I suppose I should take this to upstream?
I can’t reproduce this with Firefox 74.0.1 and bitwarden_rs 1.14.1-843604c9. Try opening Developer Tools, select All request types and check Persist Logs. Then download the attachment and see what the Response tab shows.
Hm, this is odd. I should also mention that I have the same version of bitwarden_rs as you. In the response tab, I can see a long string of seemingly random characters (which I’m assuming is the gzipped and/or encrypted file?)
Am I supposed to see some clear-text data in there instead?
That sounds normal; the response data has to be encrypted as by design, the server doesn’t have the keys to decrypt it. I’m not sure why this is happening, but it doesn’t sound like a server issue since you say it works with Chrome and mobile. Maybe try Firefox on another machine or platform and see if it makes a difference.
Yeah that’s why I suggested it might be front-end related in my initial post. Though I did check this on Firefox on another machine running a different OS and I encountered the same issue, so I’m just at a loss as to why it isn’t working for me because that would seem to suggest it’s not platform-specific either.
If the download appears in the response tab and it’s roughly the correct size, I assume the problem is decrypting the file, but that shouldn’t fail.
Might be a bit random, but are you using HTTPS? I know some crypto doesn’t work in certain browsers unless HTTPS is enabled (or you are using localhost, which is considered secure).
Also, do you have any other extensions in Firefox that could be affecting the download?
For what it’s worth, I’m using Firefox Developer 75.0b12 and it works for me both in localhost and with an https domain.
It looks to be about the correct size. The content-length header is set to 525, which is the same as on Chromium and that feels about right considering the original file is 497 bytes.
Though yeah I am using HTTPS. Basically my setup is : bitwarden_rs in docker with Caddy as a reverse proxy in front (which has auto HTTPS with let’s encrypt) and a regular domain pointing to it.
I don’t think any extension is causing the issue since I just tried in a private window (where none of my extensions are enabled) and I got the same result (on another machine running a different OS as well).
I’m just super confused at this point because it does work on my Android phone using the bitwarden app, and I tried the Firefox browser on Android just for fun, and that also gives me this weird “null” file content.
Well then I’m just stumped, I have the same caddy setup too and it works fine, can you try a different firefox version? Maybe Firefox ESR or Dev Edition? They should be versions 68 and 75 respectively.
Yeah, I have no clue either. Still the same issue in Firefox developer edition as well, though I couldn’t try with ESR because I’ve had issues with installation.
I tried downloading the actual bitwarden app on my desktop as well and this works as expected, so this really does seem like it’s very Firefox-specific for some awfully obscure reason.
With the test account on your instance, I can reproduce the issue on Firefox. I suspect this is most likely Caddy-related. What version are you running, and what’s your config look like?
I was playing around with Caddy 2.0 beta 20 the other day, and ran into a couple of major issues with it (encode zstd,gzip basically broke everything, and WebSocket proxying didn’t seem to work either). If you have an encode directive, you might try commenting that out.
Ah well at least we could narrow down the problem this way! Thanks for giving it a try. Here is a copy of my Caddyfile. I do use Caddy 1.0 still because I wasn’t sure about running something beta for a service which I’m highly dependent on.
{my-domain} {
gzip
header / {
# Enable HTTP Strict Transport Security (HSTS)
Strict-Transport-Security "max-age=31536000;"
# Enable cross-site filter (XSS) and tell browser to block detected attacks
X-XSS-Protection "1; mode=block"
# Disallow the site to be rendered within a frame (clickjacking protection)
X-Frame-Options "DENY"
# Prevent search engines from indexing (optional)
X-Robots-Tag "none"
}
# The negotiation endpoint is also proxied to Rocket
proxy /notifications/hub/negotiate bitwarden:80 {
transparent
}
# Notifications redirected to the websockets server
proxy /notifications/hub bitwarden:3012 {
websocket
}
# Proxy the Root directory to Rocket
proxy / bitwarden:80 {
transparent
}
}
Hmm, yeah nothing that looks too unusual. Maybe try removing gzip to see if it matters. You might also try temporarily removing Caddy and just enabling TLS in bitwarden_rs to prove Caddy is causing the difference in behavior.
And I can confirm that removing gzip in my Caddyfile also fixes the issue! Thanks so much for helping me out with this @jjlin@dani, I would have never figured it out on my own. I edited https://github.com/dani-garcia/bitwarden_rs/wiki/Using-Docker-Compose to remove it from the example Caddyfile to save others the trouble!
BTW, I retested this with Caddy 2.0.0 and Firefox 76 yesterday, and encode gzip seems to be working, though I’m not sure if that was ever actually an issue in the recent 2.0 betas.
