mirror of
https://github.com/dani-garcia/vaultwarden.git
synced 2026-04-26 01:35:54 +03:00
[GH-ISSUE #929] [ISSUE] Websockets Not Working #660
Labels
No labels
SSO
Third party
better for forum
bug
bug
documentation
duplicate
enhancement
future Vault
future Vault
future Vault
good first issue
help wanted
low priority
notes
pull-request
question
troubleshooting
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/vaultwarden#660
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mokshmridul on GitHub (Mar 26, 2020).
Original GitHub issue: https://github.com/dani-garcia/vaultwarden/issues/929
Hi,
Websockets not working / syncing between Chrome Client and Web Page
I had websockets working previously, but I am not getting this error:
WebSocket Protocol Error: Unable to parse WebSocket key.The error appears when accessing both the internal IP of
192.168.0.11:3012and the external server through the internethttps://vault.example.in/notifications/hubMy Docker Compose is as follows:
My NGINX Reverse proxy is as follows:
Your environment
https://vault.example.inand Chrome Addon ClientExpected behaviour
Websocket Sync to happen instantly upon changes in either client
Actual behaviour
Websocket Sync is not happening upon changes in either client
Relevant logs
@jjlin commented on GitHub (Mar 27, 2020):
I sent a PR for the
Missing id or access tokenissue, which I'm seeing as well. I don't get theUnable to parse WebSocket keyerrors, though. Maybe this is caused by the first issue in your setup, we'll see.@mokshmridul commented on GitHub (Mar 27, 2020):
Hi,
What "first issue" are you referring to in my setup? Do i have something setup incorrectly?
@jjlin commented on GitHub (Mar 27, 2020):
No, I just meant maybe the
Missing id or access tokenissue is triggering theUnable to parse WebSocket keymessage on your setup for some reason. I don't see the latter message on my setup.@mokshmridul commented on GitHub (Mar 27, 2020):
Okay, thanks for the input.
@mokshmridul commented on GitHub (Mar 27, 2020):
Im sorry to ask, but i understand that the commit was merged into the latest build (digest 0035b5d8b0a3), and i have updated to this version. however i am still getting the error.
@jjlin commented on GitHub (Mar 27, 2020):
Your
Missing id or access tokenerror is gone. I'm running 1.14.1-ec608390 with HAProxy, and WebSocket notifications are working fine for me.Given that you said you had it working before, I'd suspect that you changed something in your configuration somewhere, so maybe reflect on what that could be. Based on the error message, it looks like the
Sec-WebSocket-KeyHTTP header isn't making it through to bitwarden_rs for some reason. If you're also proxying through Cloudflare, you might take a look at any firewall rules and such that you have there. Finally, you might try running a WebSocket test client/server and making sure that works properly (e.g., see https://www.nginx.com/blog/websocket-nginx/).@mokshmridul commented on GitHub (Mar 27, 2020):
I am running it through a Nginx and through Cloudflare. However as i mentioned, even when i go directly to the internal IP
192.168.0.11:3012i get the same error, which leads me to believe that its not an error with Nginx / Cloudflare.I tried reverting to my previous settings, but its still a no-go. Any ideas as to where i could look further? I am just going to check if maybe its something on my firewall (pfsense).
Note: It seems like the connection is going through, but something else is going wrong. Im basing this on the following lines in the log file
Edit: Okay so the functionality is working fine as of now, but im still getting the error mentioned above. Am i doing something wrong?
@jjlin commented on GitHub (Mar 27, 2020):
Do you have a regular HTTP client somewhere trying to do a GET on http://192.168.0.11:3012/notifications/hub? That's exactly the error you would get since a non-WebSocket client wouldn't know to send a
Sec-WebSocket-Keyheader. Your test where you "go directly to the internal IP 192.168.0.11:3012" is invalid for the same reason.@mokshmridul commented on GitHub (Mar 28, 2020):
Okay, that makes sense now. Thank you for the quick help on this one.