Sec-Websocket-Protocol response, perhaps with custom upgrader

[vladvelici]

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?

[FZambia]

@vladvelici hello!

First of all - have you considered using JWT authentication over built-in library JWT support?

I mean that on client side you can set JWT with

centrifuge = new Centrifuge(...);
centrifuge.setToken('<JWT>');

where JWT should follow rules described here - https://centrifugal.github.io/centrifugo/server/authentication/

?

[vladvelici]

Hi! I didn't actually see that before. I saw some JWT related stuff but I didn't notice it was for exactly this purpose. I probably can remove my auth middleware and just use this instead but it'll have to wait until I make the changes (other pressing issues first).

Thank you for the quick reply!

I don't really need to be able to specify the header anymore assuming the JWT stuff here works as I think it does. I'm closing this issue (I hope that's OK, doesn't seem needed anymore) - thanks again for the reply.

[FZambia]

@vladvelici feel free to reopen if it wont work for you. BTW if current JWT format does not fit your case there is also a way to do custom JWT parsing and authentication inside ClientConnecting callback.