How to reconnect with new JWT in handshake

[Nosfistis]

I have a case where I authenticate using a standard Bearer token strategy, with expirable JWT tokens. I use NestJS gateways server-side, and with authentication guards that check the handshake for permissions.

Once the token expires, I disconnect the previous client and send a new connection with a new client. Is there any other way to update the connection auth, or trigger automatically another handshake, without reconnecting manually?

Or is WS authentication meant to be validated only on initial connection?

I have checked #3902, but this requires a reconnection. That reconnection either needs to be manual (socket.disconnect().connect()), or the server needs to disconnect in a way that the client can auto-reconnect (which does not seem to cause a re-connection).

[darrachequesne]

Or is WS authentication meant to be validated only on initial connection?

It's up to you. You can either keep the existing connection alive with an expired token, or you can either force the reconnection, with:

• either socket.disconnect().connect(); on the client side
• or socket.disconnect() on the server side, and then you catch the disconnect event:

socket.on("disconnect", (reason) => {
  if (reason === "io server disconnect") {
    socket.connect();
  }
  // automatic reconnection
});

See also:

• https://dev.to/kleeut/authenticating-websockets-21lo
• https://devcenter.heroku.com/articles/websocket-security
• https://www.linode.com/docs/guides/authenticating-over-websockets-with-jwt/

[Nosfistis]

Thanks for the reading material. The first one described the available options very well. I have opted for manually reconnecting on the client side.

Could that functionality could also be handled by socket.io (reconnect using new auth). I see that every time I connect to a new namespace a 40/namespaceName,{"token":"eyJhbG"} is sent. Could I replicate that message manually?

And in any case, would it be a good practice to mutate the connection handshake server-side with the new token?

[darrachequesne]

Could I replicate that message manually?

Currently, if you call socket.disconnect().connect(), the socket will send a DISCONNECT packet (41), the connection will be closed (since there is no other active socket) and then reopened.

Source:

• https://github.com/socketio/socket.io-client/blob/8cfea8c30b113b0b6987976af9243cba6f537f30/lib/socket.ts#L856-L857
• https://github.com/socketio/socket.io-client/blob/8cfea8c30b113b0b6987976af9243cba6f537f30/lib/manager.ts#L479-L492

As a workaround, I guess you can noop the _destroy method, something like this:

const destroy = socket.io._destroy;
socket.io._destroy = () => {};

socket.disconnect().connect();

socket.io._destroy = destroy;

That way, the socket will send a DISCONNECT packet (41) and then a CONNECT packet (40...), without closing the underlying connection.

Note: if you use multiple namespaces, calling socket.disconnect().connect() will not close the connection

We could maybe add a reconnect() method for this use case, if there's enough demand.

And in any case, would it be a good practice to mutate the connection handshake server-side with the new token?

I'd rather do manual reconnection, so you are sure that all middlewares are properly applied.

[Nosfistis]

I do actually use multiple namespaces, and perhaps this is why I do not always see a new connection (actually I often notice a new connection with the previous messages included in the dev tools).

[pastukhvladyslav]

@darrachequesne is socket.disconnect().connect() solid? My back-end emits events about new orders created, is it possible that the event is emitted within the reconnection period and I do not capture it on my front-end?

[darrachequesne]

@pastukhvladyslav any event sent during the disconnection period may indeed be lost, you'll need to fetch them upon reconnection (like for any disconnection).