I have a UI built with the (fantastic) UI Builder node, with the base path set to ui. I'm hosting this behind a reverse proxy with the path of /ui* to properly forward for example both /ui/index.html and /uibuilder/vendor/vue/dist/vue.min.js. This led me to the idea of using that same proxy route for a Node-RED based API, by using a http-in node that responds to requests to /ui/<something>. After testing, this seems to work fine.
I'm not sure how exactly Node-RED/UI Builder handle requests in this case. But with some testing it seems that if the route conflicts with UI Builder (if I try to listen to /ui/index.html with an http-in node), UI Builder wins and the real index.html is served instead of my http-in node receiving and responding to the request. If they don't conflict, everything works nicely and from the UI at /ui/index.html I can ping a http-in node at /ui/<something> and get a response back.
So I guess my question is, should I be worried that this behavior may change in the future? Can I rely on my own routes under /ui*not being blocked/responded to by UI Builder as long as they don't conflict?
Julian (@TotallyInformation) and I had a similar discussion just a few months ago, as I was looking for a simple way to serve my stand-alone nodejs application's UI and API endpoints from node-red. It was dead simple to set up a new ui_builder root node (i.e. as /myapp), check out the myapp repo into the uibuilder directory, and serve all the front-end pages as '/myapp/ui/index.js'.
The tricky part for my use case was that I already had dozens of back-end rest apis defined as express routes on a separate port in 'api.js'. Julian showed me how to add those to an express router function, which could be added to ui_builder, and effectively served as '/myapp/api/xxx' endpoints -- just what I needed! And I suspect would work for your situation as well. By the way, I would suggest that you do not use the same root url for both front-end UI and back-end API calls.
The unfortunate thing is that all of this work was done in the vnext branch, which is not due for public release any time soon. Perhaps when he gets back from holiday, we can help him debug an alpha version of code...
Yes. This is fine. Uibuilder has only a few routes of its own, mostly admin APIs which will never clash. The user routes are minimal and clearly identified. Everything else is set by you.
Personally I prefer to keep my API routes on a specific sub-path to avoid future confusion but you are clear to do whatever you want.
Well as usual I’m stuck on the security functions. I’m seriously thinking about stripping them out completely for now. The rest of vNext is pretty much ready to roll.
I’ve been tied up with work and some family issues recently so not had a lot of time. I need to get back to it though.
Let me know what you all think about the security part. Should I just pull it for now? Problem is that I made some fairly deep changes to security to try and get something more sensible but it hasn’t really worked out but all the changes are too many to revert back to the current v3 security model.
Thanks for the link @shrickus, I didn't come across it in my quick searching. Looks like it has the answer I was looking for:
As for keeping the API routes separate, you're both right and I agree. I'm currently using /ui/api/<something>, I should've made that more clear in the initial post.
That would be fine with me, since the app security comes from other upstream mechanisms. The sooner I can convert my apps from stand-alone to hosted under uibuilder, the better for me. Then I can start to migrate and/or develop new apis as necessary using more traditional node-red flows with http in endpoints.
I'm in a similar situation, authentication/authorization is handled by the reverse proxy. So I believe the only piece of UI Builder's security that I would benefit from is uibMiddleware.js to block unauthenticated users from going around the proxy and attempting to reach :1880/ui directly.
I've pushed a bunch of changes to the Github vNext branch just now so please do give them a go and see if anything is broken or not working as expected.
I've rather lost touch with where I was up to having been forced to have a break and deal with other things but I've got a few days now where I can do things in between my wife's "clearing up and clearing out" post Christmas push and giving driving lessons to my daughter!
