Is there a way to insert "middleware" to check socket responses?

[julianeden]

I have an extensive set of socket events for a browser game and I'm finding I need to individually try/catch all of the client's socket.emit callbacks for an expired/invalid session error response so I can show a "Please refresh login" type modal. Is there a better way to do this? I would love to be able to write something like~

socket.insertMiddleware('*', (response) => { if (response.error) { ... } });

I see the socket.prependAny option in the documentation, but it doesn't seem to give me a way to "stop the chain" - that is to say, if there's an error, I want to only execute the error handler and not fire the downstream happy path event listener. The documentation also says there is no error handling in socket.io, so should I infer that this is not possible?

[darrachequesne]

No, there is currently nothing built-in for your use case. We might add it though, do you have a specific API in mind?

[julianeden]

My thinking is that we would need two expansions of functionality: a way to gracefully stop the array of listeners from proceeding (thus allowing error handling), and a way to do pattern matching with namespaces for events (allowing you to apply a single listener or error handler to a subset of all events, instead of having to do each one individually).

I thought about the first issue for while because all sorts of questions started to arise once I considered it. I can start to see why it's not trivial. One way might be to let the user set validate and onError handlers for a given event, and let the validate handler choose whether to proceed or error out, like so:

// This optional handler is the first thing called when 'myCustomEvent' fires.
// If it isn't defined, we just proceed with listeners as usual
socket.validate('myCustomEvent', (errorHandler, next, ...args) => {
    if (args.error) {
        // Calling this automatically interrupts the listener progression. none of them fire. *IF* onError is defined (optional), that is called in their place.
        errorHandler();
    } else {
        // Calling this proceeds with the listener array as if nothing had happened
        next();
    }
});

// This is also optional. if it's defined, it's what's called by `errorHandler` from the `validate` handler.
// If this is defined for a given event but `validate` isn't, this has no effect.
socket.onError('myCustomEvent', (...args) => {
    // user-defined error-handling logic here
})

socket.on('myCustomEvent', (...args) => {
    // same as usual - the first listener for this event
});

socket.on('myCustomEvent', (...args) => {
    // same as usual - the second listener for this event
});

I think one pro of this is that it's backwards-compatible. No existing projects would break. They can optionally add validate/onError, but nothing changes if they don't have them defined.

I could see an argument for not needing the onError, only validate. Technically, anything the user would put in onError could also just be put under the if (args.error) branch of the conditional logic in validate. I like having these separate because it feels like a cleaner separation of concerns to me, and allows one validator to work for many different events which may individually prefer to handle their errors in different ways (or vice versa - one error handler but different validators).

---

The second problem is much more straightfoward - just allow for pattern matching in the event names, like so:

// this one would apply to all events
socket.validate('*', (errorHandler, next, ...args) => {
    
});

// this one would use event namespacing and would apply to any event starting with "users:", e.g. "users:create", "users:delete", "users:updateProfile", etc
socket.validate('users:*', errorHandler, next, ...args) => {

});

Of course one issue is that this support for namespacing is not backwards-compatible. A project that happens to have event names that conflict with the namespacing syntax, could break or experience unexpected behavior. So something like I've described here might require a major version, or otherwise an off-by-default config flag.

I imagine the validate handler would have a hierarchical precedence of specifity where a handler that EXACTLY matched the event name would be first choice if defined, one that matched the event namespace would be second choice, and the * handler would be the fallback. Only one validate is ever called for a given event.

One thing missing from this design is that it only allows for error handling at the beginning, based on validation of the server response. If a user wanted to stop midway through a series of listeners based on the results of the listeners that have already finished, that is not possible here.

That seems more difficult to design and I'm not sure if it's valuable to other users - personally I wouldn't need that capability.

Anyway this was a fun exercise and I'll be very interested to hear your thoughts! I appreciate your work on this project and thank you for the response.

[julianeden]

@darrachequesne wondering if you had any thoughts on this! No worries if you think it's not a great scheme :)

[darrachequesne]

@julianeden could socket.use() suit your use case? (only for incoming events, on the server side)

io.on("connection", (socket) => {
  socket.use(([event, ...args], next) => {
    if (isAuthorized(event, socket.data)) {
      next();
    } else {
      // do something, maybe close the connection
    }
  });
});