Websocket error log cannot be disabled

[pichouk]

Websocket error log cannot be disabled

When I set the variable LOG_LEVEL = "off" I still have log messages because of websocket malformed requests.

Encountered an error: WebSocket Protocol Error: Unable to parse WebSocket key.                                                                                                                                                                             Enable a logger to see more information.

Deployment environment

I deployed Vaultwarden using Kubernetes, on AWS. I use the container image vaultwarden/server:1.23.1.
I expose Vaultwarden using a AWS Application Load Balancer, which regularly send healtchecks to the container. Those healthchecks does not support Websocket, and I can't disable them. So I have malformed requests on the Websocket port.

I just want to hide the error message generated by the container when receiving a bad request on Websocket port.

Steps to reproduce

Start a Vaultwarden server with LOG_LEVEL="off" and send an HTTP request (using curl) to the websocket port.

Expected behaviour

I think those error logs should not be present when using the LOG_LEVEL="off" configuration.

Actual behaviour

I still have this messages

Encountered an error: WebSocket Protocol Error: Unable to parse WebSocket key.                                                                                                                                                                             Enable a logger to see more information.

[BlackDex]

This is not something we can fix, since this is build-in into the library used for the websockets.
https://github.com/paritytech/ws-rs/blob/24511a9d4ba5e485f625b9c90d0e4d5b2ec01243/src/handler.rs#L63-L70

Also, if you see this error, then you probably have configured your reverse proxy incorrect, or, if not using a reverse proxy you need to disable websockets at all via WEBSOCKET_ENABLED=FALSE.

Also see: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-WebSocket-notifications
And https://github.com/dani-garcia/vaultwarden/wiki/Proxy-examples

[pichouk]

I don't want to be rude or something, especially with OSS developers, but I think the issue have been closed a bit quickly 🙂

The issue is not really my reverse-proxy configuration, notifications are working fine. But when someone query the websocket port with a bad request (in this case it's my load-balancer health-check, but it could have been some random bot on the internet), an error log is printed even if the log level is set to off, which doesn't seems to be the expected behavior.
So according to me there is an issue here.

That being said, I perfectly understand that this message is being generated by the ws-rs library (which don't care about the Vaultwarden, configuration). But it seems that the library itself have a log level configuration, which may be map to the Vaultwarden one ?
I don't know, I'm not a Rust developer (or even a developer) but I feel that a solution may exists with this issue. Of course I'm not saying that you have to do it for me, it's OSS, but I think the Github issue is legit.

[BlackDex]

If you carefully check the lines i pasted it checks if the logging is disabled, and if so, it will print anyway.
It also even states to enable a logger to get more information, which indicates it know logging is disabled.

Basically it does this.

if 'logging is disabled' then 'print this message'

So, on the Vaultwarden side, there is nothing we can do. At least not easily.

[BlackDex]

And, regarding a solution, sure, there are ways to fix it. Report a bug to the library (But that isn't possible), a PR seems to only option there (https://github.com/paritytech/ws-rs/pulls). Fork the project (Long live OSS) and fix it and use a forked version, which i would not prefer.

[pichouk]

My bad, I didn't understand correctly the code, I thought it was easier. 😬
As you said, reporting an issue on the forked library is not possible. I will consider directly submit a PR an the forked library in order to have this in Vaultwarden.

In any case, as you said, it's not on Vaultwarden side. Sorry for the noise.

[BlackDex]

No problem! If it was something we could have fixed on the Vaultwarden side it would be great.