I don't think it would. Because you have the same issue. The URL is only tied back indirectly to the uibuilder instance. There is currently no way to consume the extra URL info as an output from uibuilder.
Though certainly I could add an option to allow that to happen - that could be part of my longer term advanced option 1 above. If you selected a flag in uibuilder, it would return some Express and/or Socket.io information to the output messages. But that isn't there at the moment.
Ah, good thinking, that should help as you can then extract the extra URL parameters in the front-end and include them in any messages you send back to Node-RED. So actually, that would be OK.
But then there are other ways to achieve the same ends without URL parameters too. For example, give the users an ID (but no password unless you want to) and have a UI element that lets them enter it. Save that in the browser in local storage so that it is retained - 1 line of code to save, another to retrieve on startup/reload. A simple wrapper function to include the data when you want to send a msg to Node-RED.
Either should work.
Hmm, not sure there is actually that much difference in terms of flexibility. option 1 gives immediate access to the extra data on the output messages and so is the more "node-red way". Option 2 requires you to write some JavaScript code in the right format but indeed could end up giving you more options at the cost of more complexity.
Might end up with both. Probably not a lot of effort to make them happen.
I will add both options to the backlog and see where that goes.