核心概念
安全模型
Kunkun 如何隔离扩展——进程边界、预加载通道白名单以及信任模型。
权限决定了扩展可以做什么。本页介绍主机如何在权限检查之前就将扩展隔离。
隔离层次
| 运行时 | 隔离方式 | 说明 |
|---|---|---|
Custom-View（BrowserWindow） | 每个扩展的源隔离（kunkun-ext://{id}） | contextIsolation: true，nodeIntegration: false |
| Worker-View（Web Worker） | Worker 沙箱 | 无 DOM，无 Node |
| Node-View / headless（Deno） | 进程 + Deno 权限标志 | 按域网络，限域文件系统 |
| Node-View / headless（Node v20+） | 进程 + Node 权限模型 | 比 Deno 更粗粒度 |
预加载通道白名单
主应用窗口和插件窗口使用不同的预加载桥：
- 主窗口允许所有
kkrpc-*通道（它就是受信任的应用）。 - 插件窗口仅允许为该窗口注入的一个 kkrpc 通道（
kkrpc-plugin-{id}），以及使用主机制发的令牌注册的后端中继通道。受信任应用的主通道被直接阻止。
纵深防御
即使预加载过滤器被绕过，kkrpc 的 ElectronIpcMainIO 也会验证发送者的 WebContents 并丢弃跨窗口消息。必须两个独立检查都失败，插件才能到达另一个窗口的 API。
信任模型一句话总结
主机从不信任插件代码声明的身份或授权；它从自己创建的连接中推导出你的身份，并自行强制执行每条权限。
具体来说：
window.__kunkun__启动信息是数据，不是令牌——编辑它不会获得任何权限。- 你的
extensionIdentifier由主机绑定到通道；你无法冒充另一个扩展来读取其存储或使用其授权。 - 跨越边界的事件负载仅限 JSON 可序列化数据。
- 受信任的
MainAPI（由应用自身的渲染器使用）从不暴露给插件。
如果你在构建主机或贡献代码
桌面壳对自身的要求清单：
- 每个
BrowserWindow上设置contextIsolation: true、nodeIntegration: false。 - 插件窗口加载插件预加载脚本（指定
allowedChannels），绝不加载主预加载脚本。 - 后端中继通道要求由主机制发的每个窗口独有令牌。
- 面向插件的 API 验证所有输入，绝不信任调用者提供的身份。
- 保持受信任表面最小化——主通道上不允许任意
exec/fs。
参见架构 → 调用者身份了解此模型所基于的会话模型。