I have just needed to manually code up a web socket client function node, in order to pass custom headers (i.e bearer token) to a WebSocket server
I was surprised this is not already allowed.
As per guidelines, I am putting it here, before I maybe put up a PR to add custom headers in client mode.
it will be similar to setting headers in the http request node, only the values will only be able to be set from a static string or env, flow or global due to the connection not being made lazily.
Is there a blocker stopping this enhancement?
any areas of concern?
I vaguely remember this being asked for previously? If so, can't remember the outcome.
I can't think of a reason you wouldn't want this. Though the documentation should make it clear that custom headers are only valid when a websocket makes its initial http(s) connection. They disappear when the connection upgrades to ws(s). And obviously, you should not be passing bearer tokens without using https/wss.
So bearer tokens on websocket connections are only good for the initial connection, you cannot, for example use a JWT to track a session when using websockets. You have to include the JWT in the ws messages instead. Socket.IO has a client auth object that lets you pack custom information into the client connections to help get round this issue.
The initial auth token was just the example I needed to work with today.
But got me thinking why custom headers aren't already supported, when the ws module fully supports it.
Allowing support should be trivial, so shouldn't take me to long to implement the enhancement, if it gets the green light.
