Have spent just over an hour reading threads here, the uibuilder wiki and the projects GitHub many pages and cant find an answer to this question....
Is uibuilder multiuser aware?
My main pain point with the Node-RED dashboard is my search page. If one person searches, everyone sees their results and if another person does a search before the previous one is done reading their results, that person then does their search again, over riding the... yeah, its a useless mess.
From what I can gather reading the uibuilder pages, this is still going to be an issue. Not only, but worse, it seems that using uibiulder I will need to write Node-RED code to individually handle every users search data?
Looking to replace the Node-RED dashboard, but want to be sure, be VERY sure, that the new solution will remove as many current pain points as possible.
uibuilder is capable of being multi-user that's for sure.
There are both ExpressJS and Socket.IO middleware hooks for example that let you hook in server-side logic which can include user/session handling.
In addition, since there is a control message for connecting and disconnecting clients, you can build logic flows to handle user identification, authentication and authorisation.
And if you try out the vNext branch, you will see that I've added some additional capabilities to support this more easily. Notably including the client IP address in control messages and giving each client (a web browser window/tab) a unique identifier that is independent of the socketId (which is reset if you reload the page or have a temporary loss of connection).
Even before vNext, I know that there are people who have implemented multi-user web apps using uibuilder.
And of course, you could also put a reverse proxy in place to handle identification, authentication and authorisation.
I have also been trying to add a more direct security capability to uibuilder. However, it is very complex to get this right, especially when working with both http and ws. I've still not found methods to make this both easy to use and secure. Though you are more than welcome to try it out and tell me where it should improve I wouldn't recommend it for live use though as there are certainly gaps and it is likely to change quite considerably again.
That won't happen with uibuilder if, in your flow logic, you retain the msg._socketId. If that is included when you send a msg to uibuilder, it will only go to the client that has that socket id. No other processing is required. Just remember that there are situations where that will result in the client not getting anything because something caused their socket id to change. Normally won't happen much if at all but it can happen.
No, not really. As I say, all you need to do is retain the _socketId throughout the search flow. If you need more, then you can certainly make things more robust but if you look at vNext, you will see that with the IP address and clientId along with the _socketId, you can easily build a flow that will manage multiple user sessions even if they change networks as long as they keep the browser window/tab open (the user identifier is passed via a session cookie).
Indeed. Fully understandable. And I am keen to understand how people want to use uibuilder so that I'm extending it in ways that people find useful. So I'm more than happy to have discussions about this.
Oh, and of course, not to forget that each instance of the uibuilder node gets a different websocket namespace. Doesn't really help in the case you've outlined, but it does ensure that comms channels are forceably separated. This lets you build independent data-driven web apps from a single Node-RED instance.
You clearly have put a ton of work into uibuilder. Kudos man.
IP address vs socketId.
I can easily have ~100 users connected and I know that many connect from more than one device in their house so I think I need to look at other dashboard options as tracking all those socketId's does not sound like something my skill set is up for.
Again, thanks for being upfront about the question.
If that is your only pain point & you are happy with everything else for now (i.e. while you learn and rebuild in ui-builder) then you could make the search page using endpoints and standard web controls.
You don't need to "track" them. I've tried to keep the processes so far to be as free of session tracking as possible knowing that, when you do need to add session handling - usually for security purposes - you will need to provide a store and lookup process. That is likely to mean using technologies you are already familiar with - of which there are many. So in true uibuilder style, I want uibuilder to save you some time and energy without tying you in to specific tech.
In your case, all you need to do is make sure that the data you are sending round your flows retain the socket id - that's it - and Node-RED will do that for you unless you insert something that looses the origin msg object.
Well any other option will need to do something similar to what uibuilder already gives you.
Whatever methods you use, you HAVE to have an id that comes from the client and goes back to the same client. With web endpoints, the only other option would be to implement server-side session management and that is a lot more work. Retaining the socket id is simple, lightweight and reasonably robust and requires no tracking or storage.
Yes, I think that is inevitable. But an interesting journey so look on the bright side.
I don't think so. I'm sure there are ways to work through the problem. You probably need to start with building some test flows to try out the concept.
OK, now you've made me sad!
I thought it was simple.
Add a uibuilder node, set the url in the settings, select a template. Add debug nodes to the two outputs. Deploy. Send a msg to the node. See the data in the front-end.
Have you seen the beginners guide as well?
Ah well, coding is just like any other skill. If you can think, you can code
I wouldn't recommend it for live use though as there are certainly gaps and it is likely to change quite considerably again.
