Wildcard subscription for websockets?

#1

Is it possible to configure a websocket as /wsendpoint/* to accept connection requests from /wsendpoint/john, /wsendpoint/jane etc?

Purpose would be to serve arbitrary subscribers (e.g. each user would use an own sub channel) their messages. Some header would need to specify the recipient channel (including *).

What changes to the websocket node would be required? … or is there a smarter way?

0 Likes

#2

This is not possible I’m afraid since how would the websocket server know what to listen to. Both the client and the server have to have the same URL and, unlike web servers, it isn’t possible for the server to serve a wildcard. In fact, I don’t think that would work well with real-time comms anyway.

There would be some potential workarounds you could do with something like Socket.IO that lets you create channels (rooms).

However, you might not need what you think. This is because each client that connects to the socket gets its own unique ID. So it is easy enough in Node-RED to process clients independently. In fact, this is the default. Try connecting several clients with each sending a different message and arrange the input messages to be sent back out again. You will find that each client only receives its own messages. In order to broadcast an input message, you have to remove the client ID from it.

0 Likes

#3

I had the idea since the Eclipse vert.x project had a sample of using a route /ws/* to listen to websockets. However as you pointed out, there is potentially an easier way to get what I want.

If I can get access to the session and map it to an actual user I’m done. So eventually the websocket node needs a little upgrade ;-).

What would need to be done: trigger an event whenever a client starts listening to a websocket. Pass all parameters, so the session id could be captured and eventually a parameter passed into the original request along this idea.

The interesting challenge: how to reject a listener? Usually I would use a callback that evaluates to true if connecting is OK and false if rejected. But how would I model that in a NodeRED flow?

Does that sound feasible. I could give it a crack

0 Likes

#4

Not sure if it helps - but the status node can catch the status events from other nodes on the page - so can catch the connect event from the websocket node for you.

1 Like

#5

If you do some searching around. There have been previous discussions about how to secure websockets.

You could also pass the input from the ws-in node through a function that tests a global/flow/context var to see if the client id is already known. If not, it is a new client. You could then prevent incoming data until you force the client to go through some kind of security validation. Perhaps ending up with a security token that then has to be included with every msg sent from the client. You would need to keep the token lifespan fairly short and have an auto-renewal process to mitigate token interception. Same stuff as any other token security process.

0 Likes

#6

Status Node looks interesting. It provides the Node and the message ID. Can that be used to get to the message?

0 Likes