Repository navigation
child_process: special handling of process.on('message') #13913
Description
Activity
-1 That would unnecessarily break backwards compatibility for zero gain IMHO.
@refack but couldn't some evil actor just emit IPCMessage
process.emit('IPCMessage')even if it were not an IPC message?in my code, I check for properties on the message object coming back to see if it's IPC related.
@refack but couldn't some evil actor just emit IPCMessage
process.emit('IPCMessage') even if it were not an IPC message?
in my code, I check for properties on the message object coming back to see if it's IPC related.As I see it the
nodeinternal code will have exclusivity on emittingIPCMessage. Probably need to inherit fromEventEmitterand override theemitand theregisterListenerdo validateIPCMessageevents.
A really "evil actor" could probably monkey patch something, but that is true for most of the API, sometimes for the better (i.e.graceful-fs)I still don't see any worthwhile gain coming from such changes.
(removing "good first contribution" tag as there isn't yet a consensus)
Reacted by Refael AckermannAlso -1. Adds complexity and overhead for unclear benefit and feels a bit like a solution in search of a problem.
Closing for lack of consensus 🤷♂️
has a special meaning in the context of IPC between parent and child. The problem is a
'message'event could be triggered other code, or listened to outside of IPC context, so we can not do any special treatment for it.I suggest adding
'IPCMessage'that only the IPC channel can trigger, and registering a listener to would fail if an IPC channel was not established.Ref: nodejs/help#693 (comment)
[edit]
The intention is to emit both events:
messagefor backwards compatibility, andIPCMessagefor a validated IPC only events.