Update ui.js

[ebertech]

copy the meta field from the original message if it exists.

I'd like use be able to annotate messages as they come in and bind them to a "user" using a socket.io middleware. This way, I can do the lookup once on establishing the connection and do a socket.use() handler to add that field to each update-value that comes back from the UI.

Right now, each node gets to do its own munging of the received message and there's no way (that I can figure) to easily inject this info in the socket middleware. While I could, in theory, do the lookup later using the socketid, I'd have to maintain some table somewhere that maps socketids to users. That seems like a recipe for leaks, whereas this way it's just done in the closure in the handler which should get cleaned up when the socket is released.

[ebertech]

Here's an example of how I want to use it:

    ui: { 
      path: "ui" ,
      ioMiddleware: [
          (socket, next) => {
            if(socket.conn.request.headers.cookie) {
              const username = lookupTheUser(socket.conn.request.headers.cookie) // look up the user
              socket.use((packet, next) => {
                if(packet[0] == 'update-value') {
                    packet[1].meta = {username: username};                                
                }
                next();
              });              
            }
            next();
          }
        ]
    },

[ebertech]

thoughts?

[dceejay]

my concern is that although I can understand your intended use, I can see that it could be used as a means for sending anything to the front end and could be exploited for lots of other purposes (eg in a template). We deliberately don't send complete msg to the front end in order to stop leakage and to minimise traffic.

[ebertech]

Hi, maybe I'm not following. This is only on the way in from the front-end, not on the way out...

Or are you saying, that while my usecase is ingress, it can be abused to do egress as well? I mean... if people want to be awful they could be... but isn't that on them? They'd have to actively go in and try to mess with it.

[dceejay]

indeed - you are correct. must wake up before looking at code. Happy to merge.
Note the Dashboard is still not inherently multi-user - all running on the single thread that is the Node_RED node application so I don't think this should be considered a way to truly enable multi-user - though I can see it helps separate your concerns.