How to enhance 'websocket in' with basic authorization header?

my local smart home system has some "special requirement" on how to connect to their websocket:
(...) you require a websocket implementation that: Supports providing headers to the connection request.

I cannot find any way to enhance the built-in 'websocket in' node with an authorization header for basic auth, or any proper "workaround"...
I have already tried node-red-contrib-custom-header-ws, but that node does not run stable.

Are there any ideas? I am also open for suboptimal solutions regarding security, it is only within may LAN... :wink: It has to be a stable connect at least.


Well, that is annoying - I've searched through the flows can I can't see anything that does what you want surprisingly. Lots of custom websocket connections to specific endpoints but nothing generic I can see.

First step would be to raise a GitHub issue against that custom-header-ws node to see if the author is responsive.

However, it really it needs the core websocket node enhancing to allow specification of headers. Not that uncommon a requirement. You could submit it as an enhancement request but I'm not sure who might have bandwidth to work on it if you aren't able to do a pull request yourself.

@knolleary or @Steve-Mcl - any other thoughts?

I will try to contact the author (lorenzhoh) directly with my findings and analysis (have already an idea what's going wrong). But the package has been deprecated:
So I do not expect a solution.

Fully agree with your valuation. Also thought that it should not be such an uncommon requirement, but did not find any generic custom node or flow either solving these problem.

Unfortunately I am not able to implement that enhancement and raise a pull request (due to lack of coding skills ;-))

I have raised an issue on GitHub.
Let's see if 'Lorenzhoh' can support or fix it. Or maybe implement the 'header authorization feature' within core websocket node and raise an PR?


I recently updated Lorenzhoh's library. It now accepts a Bearer Token for authorization and returns the message in JSON-format. You can find the new npm package here.

If you need another type of authorization header, you're welcome to raise an issue on GitHub

Sorry @deltaecho07, but I don’t see any relation to topic and thread above.

Anybody with capacity who is able to implement “header authorization feature“ within core websocket node and can raise a PR?

I do not agree with you @b0denl0s. You can use my node to connect to a websocket with an authorization header and thereafter you get all the messages sent by the ws-server. If you need to be able to send some commands to the ws-server, let me know.

My understanding @deltaecho07

  • I need basic auth ->> I understand your solution provides bearer token for auth; as I can see in your code Authorization: Bearer is hardcoded within your initial request header and you append the token string only. For basic Authorization: Basic is required. However, lorenzhoh's library works fine with basic auth. No need to change this part in lorenzhoh's lib.

  • But lorenzhoh's implementation has an issue regarding disconnecting/reusing WS connections as I explained here as an issue. You mentioned you updated his library regarding authorization ->> I presume that you have re-used these parts of his implementation dealing with disconnecting/reusing ws? If so I do not expect any difference in behavior.

So please let me know what I did not unterstand or presume correctly. :slight_smile:

@b0denl0s sorry I misunderstood you! I thought you also need the Bearer Auth...
The issue of lorenzhoh's library is that it has a second header attribute which can cause troubles if you leave it blank.

Long story short: you need a library that is capable of connecting to a WS with basic authentication header. Do you need just a subscriber? Or do you want also to send messages to the WS server?

Once I have your answer I will create a new library with the basic Auth header for you. :slight_smile:

Yes, and yes. :slight_smile:

But I would suggest the following: Due to the fact that build in core websocket node is really stable and robust. Would you be able to implement an enhancement to allow header specifications (Bearer token, Basic auth string,…) and do a pull request on these core websocket? I think that will be the best solution, because it is a common and quite central option. That would be great!

I assume you are using free@home as myself.
To get the connection working you just need to put in the URL of the websocket the username and password in plaintext. Securitywise this might be a concern, but since you are using a local API and staying withing you network you might dare to do it.

So the URL will look like this: ws://username:password@192.XXX.XX.XX/fhapi/v1/api/ws

After that it works. I used it to listen to one of my pushbuttons. So if the button gets pressed and light is already on, it switches the color of the light to a specified next color in a loop. That way I can switch my colors of the philipps hue with a simple rocker.
Hope this helps.

I try to connect to a websocket server which requires a Basic authentication with node red but it doesn't work. Using Postman with the websocket client authorization it works fine, so I think I miss something in the Node-Red configuration. could you help me?

Here the conf for the Custom websocket subscriber:
Name: empty
wss-URL: wss://
X-Client-Id: empty
Authorization: Basic b3BlcmF0b3I6U2NobmVpZGVyPTE=

the string correspond to the login:password in base64 format.
It works fine with postman I can connect to the server, here the log:
Connected to wss://
Handshake Details
Request URL:
Request Method: GET
Status Code: 101 Switching Protocols
Request Headers
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: NRVvndm0vfoQ7oT1DGmasA==
Connection: Upgrade
Upgrade: websocket
Authorization: Basic b3BlcmF0b3I6U2NobmVpZGVyPTE=
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

With Node-Red I have always the message: "Could not connect to server"


This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.