feat: add a getScopedToSender API on ipcMain

[MarshallOfSound]

Description of Change

This solves the usecase where folks for either security or use-case reasons only want to listen for message X coming from webContents Y.

Instead of checking the sender or sender.id each time and hoping you don't miss a listener or writing your own abstraction around IPC (let's be real a lot of us have done that before) this provides a low-overhead first-party API for solving this problem.

This use-case has actually come up in internal core code as well so we can benefit from this API internally. E.g. #17416

I'll add tests and such if we're happy with this approach.

Release Notes

Notes: Added a new ipcMain.getScopedToSender API to create ipcMain instances that only emit IPC messages from a specific webContents

[zcbenz]

The code looks good to me, but I don't have experiences with securing IPC messages so I'm not sure whether the API design is reasonable.

I think we should have actual users commenting whether they would use this API.

[nornagon]

This seems like it adds significant complexity and I'm not sure I understand the use case fully. Could you elaborate on the problem you're aiming to solve & maybe list some alternative solutions?

[MarshallOfSound]

@nornagon The high level use-case is the opposite end of targeted sending of messages.

Currently we can say: Send this message to exactly this webContents
But there is no easy way to say: Only notify be about messages from this webContents

Example use cases for caring about that are per-webcontents features or security scoping of IPC messages (you only expect a particular webContents to respond to a certain message).

Either you get messages from all webConents with ipcMain.on('X') or you have to manually filter IPC messages with webContents.on('ipc-message').

The intention of this API is to provide a minimal overhead way to subscribe to a given message from a given webContents.

[miniak]

@MarshallOfSound any progress on this?

[miniak]

no need to check event.sender.id anymore

[codebytere]

Is this ready to be merged @MarshallOfSound?

[miniak]

@MarshallOfSound can you please rebase and resolve the conflicts?

[nornagon]

I'm still somewhat concerned about the complexity here, but separately from that, I think the API should rather be something like

webContents.ipc.on(channel, handler)

rather than being a method on ipcMain.

[miniak]

@nornagon I was proposing webContents.ipc

[miniak]

@nornagon #16420

[miniak]

It needs to be updated to support invoke/handle

[zcbenz]

According to the discussions at #16420 and #16468, it seems that this PR is no longer needed since webContents.ipc was proposed to replace this and then webContents.ipc was replaced by the ipc-message event.

So I'm closing this PR. Please reopen this if anyone still wants to continue this direction.