Hello,
I'd like to thank to Julian and all involved community for the development of node-red-contrib-uibuilder. It's amazing job.
I spent a lot of time during last year learning Node-red, fallowing posts, docs, videos, I saw many conversations like what is better, uibuilder or contrib-uibuilder, javascript or python, this or that. As someone said, and as a senior electrical engineer I can fully admit, everything is good and bad at the same time, depending of the need where you want to apply it, and your preferences and choice.
When talk about dashboard, for making nice looking professional dashboard, using of front end libraries is mandatory, in my opinion, and there's a big need and advantage for contrib-uibuilder compared to official uibuilder in that field. Simplicity is excellent but it's not omnipotent.
What I can't accept with uibuilder is it's autogenerated url. You type localhost:1880/ui and you get for instance: localhost:1880/ui/#!/0?socketid=AaMwa6tsf7Zw2sg9AAcS
With contrib-uibuilder, you type localhost:1880/table for instance and you get your dashboard on the same url. That's it, no any extension in url, sockets ID etc. In the first case I frankly don't feel good as I don't know whats going on behind the scene. Despite the awareness of the complexity of the mechanism which provides connectivity of front end with Nodered, second one gives me much more confident, to be honestly.
But, what I'm still missing is an example of login mechanism?!
Can anyone provide a working example for user authentication on nodered-contrib-uibuilder V5 dashboard? It can be the simplest one, on one page, w/o multi pages for registration, login and so on, and w/o any db stored credentials. One good example of authentication I found is node-red-contrib-users but I don't know how to merge it with node-red-contrib-uibuilder. Can someone help?
Many thanks and regards
Can we just be clear here - there is only 1 uibuilder 
The main alternative is called Dashboard. Then there are 1 or two other UI building contrib nodes some of which aren't particularly supported or are just getting off the ground.
But currently, Dashboard (maintained in core mostly by Dave with additional contributed ui-xxxx nodes from others) and node-red-contrib-uibuilder (or just "uibuilder" for short) which is mostly developed and supported by me with some notable contributions by others.
Dashboard is aimed at folk who need to rapidly put together a user accessible Dashboard but who generally don't want to do coding for it. uibuilder is aimed at creating general-purpose, data-driven web apps backed by Node-RED. uibuilder can, of course, also build Dashboards but it can do just about anything you can think of doing with a web app. But you need to write at least a small amount of code.
Python and other things you mention are different really and we could unpack that separately if needed.
Which was one of the drivers behind the creation of uibuilder. But, Dashboard has been a massive boon to Node-RED as it meets the same low-code aspirations of Node-RED itself and means that non-coders can create UI's and even coders can throw something interactive together quickly.
Then don't use Dashboard 
But seriously, if you need to simplify or change that url, it is possible by using a reverse proxy service. However, it is what it is because of the tools used to create the framework. The same framework that makes its use simple.
Dashboard is complex so that usage does not need to be complex to use. That is the nature of frameworks. With uibuilder, there is an expectation that you will know or learn at least some basic skills in creating and managing HTTP/HTML/CSS/JS/WEBSOCKETS apps. You don't actually need a lot but you do need some.
Remember that Dashboard was originally built by a contributor and gifted to Node-RED. It uses v1 of the Angular framework which is one of the older and more complex frameworks. Dave gamely stepped up to the plate to try and support it and develop it. But at the end of the day, the underlying code is extremely complex and build around a deprecating framework.
Nice of you to say so 
I think that everyone agrees that a new Dashboard capability is needed for Node-RED. But as yet, nobody has fully stepped up to create one. Though TVE is busy creating something and I've been trying to work uibuilder towards a foundation platform that a no-code dashboard can be build on and have provided some examples of how that might work (but I don't have the time to do the whole thing at the moment I'm afraid).
I took a difficult decision to pull the dedicated login and other security processing from uibuilder for v5. The reason being that it is very hard to get right and it ended up holding back other beneficial developments.
My recommendation for securing Node-RED based UI's, regardless of how they are delivered, however is to use external authentication and authorisation.
As such, I spent some time starting to put together examples for uibuilder (that could fairly easily be adapted to Dashboard, etc).
Using NGINX for authentication and authorisation to Node-RED - FAQs - Node-RED Forum (nodered.org)
The issue is that there are a great many ways to secure a web app and things can quickly get complex when you try to do things that are genuinely secure. Be very sceptical of tutorials that make it seem simple. I do enterprise and government-level security in my day-job so I do know a bit about it.
The next example I'm working on will be more complex but more realistic that the above. But it will still use NGINX to provide the security wrapper.
In the meantime, by using the "new" client library for uibuilder, you get access to additional client information such as IP addresses and a more stable client UID that you can use to provide some basic security along with HTTP Digest authentication via NGINX from the examples.
You see, I've been so heavily using uibuilder that I renamed dashboard to "official uibuilder" . It's a compliment, isn't it?
Joke aside, thank you a great deal for your prompt response!
I think the thread already became very useful as clarifies some key points of development, design and history, but also stresses some still painful ones.
In my eyes delivering uibuilder w/o minimum authentication feature is like an ice cream in a cup without a spoon 
You sent me two general links, that I've already seen, and could not use, as:
- I don't like to install NGINX as the second web server on my Raspberry Pi, beside Node.js
- this is general theoretic explanation that is far from real example
Uibuilder is the best used to make one page dashboard, right? Is it such big deal to make login example for one page app?
I would be more happy if uibuilder would have "is logged in" node than to use it as none-code platform one day.
kind regards
I'll take it 
But it is easy to get people confused & I'm always fighting with getting people to be explicit and detailed in my day-job so this is a hard to avoid habit.
And I've fought with that problem for several years now! The problem is that delivering a spoon full of splinters is as bad as not providing one. If everyone understands that authentication at least should be done externally then at least everyone knows that they need to carry a spork with them (which I do when I'm travelling with work as I've been caught out too many times).
So the documentation for uibuilder is completely clear now. Do authentication externally.
I then try to continuously improve the documentation on ways to do that. But remember that uibuilder is not my day-job and very few people have contributed to it. I do what I can and would love to do more. It takes a lot of time.
Of course, I am always open to submissions not only of code but examples and documentation.
Well, to be fair, not my problem. You want an example and you get one that is performant, secure, available to all - even on a Pi, and free.
Also, node.js is not a web server. And NGINX is more than a web server. ExpressJS provides node.js web services but even they recommend the use of a reverse proxy for performance and security. So this is a well known, understood and respected path.
The docs in the tech docs (you did read them all? There are more than just the 1 I linked to) are somewhat more theoretical though one of them is certainly specifc.
The example in the thread is not theoretical.
Not at all. You can create single- and multi-page apps with a single uibuilder node and you can have multiple uibuilder nodes in your flow.
Firstly, I've done that and shared it in the thread I linked to.
Secondly, yes it is a big deal. As I said, it is NOT simple to get a robust, secure web app that can be shared over the Internet.
I'm sure we all would. But as I said, I have limited time and lots of things to achieve. I've already spent countless hours trying to get something to work reliably and securely and nothing I've tried was satisfactory. It probably needs someone with better skills than mine.
When someone who knows a lot about website security considers that the best way is to not include it in uibuilder, then personally, as someone who knows only a little about security, I will take his advice. Usability and convenience for the developer is not the most important thing when concerning security, it is the security that is important and we just have to live with the inconvenience of, for example, installing and configuring NGINX.
Thank you once again for your time and quick response, I won't diverge it any more.
But please do continue to provide constructive criticism. And if you think up creative ways of doing things, or improving things, please do speak up.
And if you come up with an example, please share and I will make sure it is included in the docs or WIKI as needed.
Surely !
You did an extraordinary job and wish you much success and joy in doing it.
I will send an example when it will be ready, as I must make it with or w/o NGINX
It's really nice having such dedicated and responsive author.
regards
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
