[GH-ISSUE #535] Websocket failures are indistinguishable #410

New issue

Open

opened 2026-05-07 00:23:55 +02:00 by BreizhHardware · 2 comments

BreizhHardware commented

2026-05-07 00:23:55 +02:00

Owner

Originally created by @alexhorner on GitHub (Dec 8, 2022).
Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/535

When you're unauthroised on a websocket, wrong credentials or none provided, the response code is a 200 but the debug log on the server reports unauthorized. I think it should be 403 or 401, not 200.

Additionally, If a proxy fails and returns an incorrect page with a 200, my app says credential failure, when that definitely isn't, it's a connection failure, but it is currently not possible to differentiate this with ntfy.sh's behaviour.

Originally created by @alexhorner on GitHub (Dec 8, 2022). Original GitHub issue: https://github.com/binwiederhier/ntfy/issues/535 When you're unauthroised on a websocket, wrong credentials or none provided, the response code is a 200 but the debug log on the server reports unauthorized. I think it should be 403 or 401, not 200. Additionally, If a proxy fails and returns an incorrect page with a 200, my app says credential failure, when that definitely isn't, it's a connection failure, but it is currently not possible to differentiate this with ntfy.sh's behaviour.

BreizhHardware added the

🪲 bug

server

labels

2026-05-07 00:23:55 +02:00

BreizhHardware commented

2026-05-07 00:23:56 +02:00

Author

Owner

@binwiederhier commented on GitHub (Mar 13, 2023):

I realized that this is very very easy to do. I do not fully know how clients would react though, which I suppose is the hardest part, to test this.

It'd be to call w.WriteHeader(httpErr.HTTPCode) here: https://github.com/binwiederhier/ntfy/blob/main/server/server.go#L331-L339, maybe also adding a X-Ntfy-Error header to return the error message, or something.

Not entirely sure if there is a better way for websocket errors to return error messages

@binwiederhier commented on GitHub (Mar 13, 2023): I realized that this is very very easy to do. I do not fully know how clients would react though, which I suppose is the hardest part, to test this. It'd be to call `w.WriteHeader(httpErr.HTTPCode)` here: https://github.com/binwiederhier/ntfy/blob/main/server/server.go#L331-L339, maybe also adding a `X-Ntfy-Error` header to return the error message, or something. Not entirely sure if there is a better way for websocket errors to return error messages

BreizhHardware commented

2026-05-07 00:23:56 +02:00

Author

Owner

@alexhorner commented on GitHub (Mar 13, 2023):

@binwiederhier I'm not sure it could break clients any more than they are broken already?

Having tested, my websocket client expects a code 101 for switching protocol to websocket. It instead receives a 200 which it does not expect and causes it to throw.

Considering it never establishes a valid websocket connection anyway, and no sense can be made of the 200, I would expect that a client would already (like mine) be just rejecting anything that isn't a 101 as a fault. Being more specific about what that fault is would certainly be useful.

@alexhorner commented on GitHub (Mar 13, 2023): @binwiederhier I'm not sure it could break clients any more than they are broken already? Having tested, my websocket client expects a code 101 for switching protocol to websocket. It instead receives a 200 which it does not expect and causes it to throw. Considering it never establishes a valid websocket connection anyway, and no sense can be made of the 200, I would expect that a client would already (like mine) be just rejecting anything that isn't a 101 as a fault. Being more specific about what that fault is would certainly be useful.