I'm working on an application that provides updates to logged in users via web-socket. I don't even want the connection to be allowed for non-logged-in users and the way this was solved previously was to use the Sec-Websocket-Protocol
header in the original request (setting that to a JWT).
I've added the same thing with centrifuge and added the UserID to centrifuge just fine, but the issue is that I can't make centrifuge reply with the protocol header set, which results in errors like the following:
WebSocket connection to 'ws://localhost:5000/v1/web-sockets-pubsub' failed: Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' header but no response was received
Firefox seems fine with it and everything works well there.
As far as I know (from here) there's no other way to add auth, apart from adding the JWT to the URL but for some reason I'm trying to avoid it. I don't have a clear argument against it but something doesn't seem right to put tokens in the URL. Server and front-end are on different subdomains.
It would be great to have the option to add a customer gorilla *websocket.Upgrader
to NewWebsocketHandler()
, maybe by passing it as an option to WebsocketConfig
. If it's null, the default is used, otherwise the given one.
What do you think?
Or am I thinking about this wrong, is there another way to handle authentication that I'm missing?