OK, maybe a slight misunderstanding and some clarity on terms.
You mentioned adding to the
msg which wouldn't adding a header.
When trying to secure web apps that are websocket driven such as Dashboard, mdashboard and uibuilder, HTTP headers only really secure the web pages themselves and cannot fully secure the websocket communications as they only present additional headers during the initial handshake.
So to properly secure websockets, you need to pass data in the msg as you said. My proposal is to have an agreed format for the information you might want to transfer in order to facilitate a login or subsequent security checks (e.g. continuing to exchange a JWT token).
I am currently adding a
_uibAuth object property to the
"payload": ... ,
"topic": ... ,
"_msgId": ... ,
"_socketId": ... ,
"id": ...unique user identifier... ,
// Other potential information depending on need.
// e.g. for a login:
"password": ...encoded password... ,
// or for ongoing session management:
"jwt": ... JWT token (base 64 encoded) ...
If others wanted to pick up the same kind of schema,
_uibAuth could be renamed to perhaps just
_auth. But I didn't want to assume that if only uibuilder would be using it.
The same msg property is also used when sending information from the Node-RED server to the client as well. For example, on a successful login, you might return a message for the user from the server such as "Welcome to xxxxx, please remember to change your password" or whatever, you might also pass back other "meta-data" such as a timestamp when the users subscription expires.
Not of this implies any kind of fixed data or process other than using a standard msg property and using a standard
id property within that. It is just a convention similar to the other msg conventions that Node-RED already uses (topic and payload for example).