ArchiveBox 机器服务MachineService源码解析事件驱动的 Machine.config 持久化与二进制键白名单机制【免费下载链接】ArchiveBox Open source self-hosted web archiving. Takes URLs/browser history/bookmarks/Pocket/Pinboard/etc., saves HTML, JS, PDFs, media, and more...项目地址: https://gitcode.com/gh_mirrors/ar/ArchiveBox导读archivebox.services.machine_service是 ArchiveBox 事件驱动架构中负责「机器Machine配置持久化」的核心服务模块。它监听 abx-dl 事件总线上的MachineEvent把与外部二进制如 Chrome、yt-dlp、tesseract 等相关的配置覆盖项写入数据库中的Machine.configJSON 字段并通过文件 ↔ 数据库双向镜像机制与ArchiveBox.conf保持一致。阅读本文后你将理解为什么Machine.config允许存放任意用户配置键却只允许事件写入二进制相关键、MachineService如何区分user与derived两类事件以及该模块与安全边界、安装流程、爬取运行时之间的完整协作链路。本文基于仓库中的 autodoc 文档 archivebox.services.machine_service 展开源码与测试证据见 machine_service.py、machine/models.py 与 test_machine_service.py。模块概览公开 API 与职责边界该模块的全部公开 API 由三个对象构成职责非常收敛——它只做一件事把MachineEvent中合法二进制相关的配置持久化到当前机器的Machine.config。API类型职责_is_binary_event_key(key: str) - bool模块级函数判断一个配置键是否属于「允许事件写入」的二进制相关键_strip_to_binary_keys(config: dict \| None) - dict模块级函数从任意配置字典中过滤出全部二进制相关键MachineService(bus)服务类继承abx_dl.services.base.BaseService订阅MachineEvent将其中的二进制配置合并写入Machine.config并落库在类层面MachineService有两个关键类属性autodoc 文档中亦有明确标注LISTENS_TO [MachineEvent]声明本服务只监听MachineEvent这一类事件EMITS []本服务不对外发出任何事件是纯消费者sink。这个「只监听、不发出」的设计说明MachineService位于事件流水线的末端扮演持久化收尾的角色上游二进制安装服务、爬取运行时通过事件总线广播配置变更由它统一负责落库从而让业务代码无需直接 import Django ORM 即可产生副作用。核心实现一_is_binary_event_key—— 事件写配置的安全白名单def _is_binary_event_key(key: str) - bool: MachineEvent projector only ever writes binary-related state. Machine.config mirrors ArchiveBox.conf so arbitrary user keys can legitimately live there — but they get there through the file ↔ DB sync, not through events. Letting events write arbitrary keys would let an untrusted plugin overwrite security-sensitive user config (the file ↔ DB mirror is a security boundary), so the projector strips anything that isnt a binary path or the binary install cache. if key.startswith(ABX_) and key.endswith(CACHE): return True return key.endswith(_BINARY)这个函数定义了事件写入配置的白名单规则只有两类键可以通过事件进入Machine.configABX_前缀 CACHE后缀的键例如ABX_INSTALL_CACHE、ABX_UV_CACHE——它们记录二进制安装缓存的状态以_BINARY结尾的键例如CHROME_BINARY、LITEPARSE_BINARY、LITEPARSE_TESSERACT_BINARY——它们记录某个外部二进制的解析路径。为什么需要这道白名单注释中揭示了其背后深刻的安全考量这是本模块设计的核心逻辑Machine.config是ArchiveBox.conf的数据库镜像因此它天生允许存放任意用户配置键BASE_URL、SERVER_SECURITY_MODE、插件开关等都可能合法地出现在其中但这些任意键是通过文件 ↔ 数据库同步而非事件进入Machine.config的这是一条受控通道事件总线是插件可编程、可注入的开放通道。如果允许事件写入任意键不可信的插件就能通过伪造MachineEvent覆盖安全敏感的用户配置例如篡改SERVER_SECURITY_MODE从而突破安全边界。因此_is_binary_event_key把事件写入能力收敛到「二进制路径 安装缓存」这个小集合。二进制路径本质上来自本机探测或安装结果属于可验证的派生数据即使被覆盖也只会影响某个外部工具的执行路径不会直接改写认证、网络、权限等安全关键配置。核心实现二_strip_to_binary_keys—— 整包配置的过滤漏斗def _strip_to_binary_keys(config: dict[str, Any] | None) - dict[str, Any]: if not isinstance(config, dict): return {} return {key: value for key, value in config.items() if _is_binary_event_key(str(key))}该函数是_is_binary_event_key的批量应用版本输入一个任意配置字典可能来自事件的config字段输出只保留二进制相关键的子集。注意两点防御性细节入参不是字典例如None时返回空字典不会抛异常键被强制转为字符串后再做判断避免非字符串键导致类型错误。在MachineService的事件处理器中这个函数是「整包合并」路径的守门人当MachineEvent.config携带一份完整配置时先经它过滤再与现有配置合并。核心实现三MachineService类与on_MachineEvent__save_to_db事件处理器类定义与订阅class MachineService(BaseService): LISTENS_TO [MachineEvent] EMITS [] def __init__(self, bus): super().__init__(bus) self.bus.on(MachineEvent, self.on_MachineEvent__save_to_db)构造函数除了初始化基类外只做一件事把on_MachineEvent__save_to_db注册为MachineEvent的处理器。这意味着只要在某个事件总线上实例化MachineService该总线上的所有MachineEvent都会自动触发持久化逻辑。事件处理器的完整流程async def on_MachineEvent__save_to_db(self, event: MachineEvent) - None: from archivebox.machine.models import Machine if event.config_type ! derived: return machine await sync_to_async(Machine.current, thread_sensitiveTrue)() old_config dict(machine.config or {}) config dict(old_config) if event.config is not None: binary_only _strip_to_binary_keys(event.config) config.update(binary_only) elif event.method update: key event.key.replace(config/, , 1).strip() if key and _is_binary_event_key(key): config[key] event.value elif event.method unset: key event.key.replace(config/, , 1).strip() if key and _is_binary_event_key(key): config.pop(key, None) else: return if config old_config: return machine.config config await machine.asave(update_fields[config, modified_at])整个处理逻辑可以拆解为四个阶段阶段 1类型过滤只看 derived 事件if event.config_type ! derived: return这是第一道也是最重要的闸门。abx-dl 事件模型中的MachineEvent带有一个config_type字段取值至少包含user与derived两类见 runner.py 中config_typeuser与config_typederived两种发射方式user事件携带用户/配置文件层面的原始配置。MachineService对其直接忽略——因为这些配置会经由文件 ↔ 数据库同步通道进入Machine.config事件通道无权染指derived事件携带运行时探测/派生出的配置二进制路径、安装缓存等。只有这类事件会被接受并持久化。阶段 2读取当前机器与现有配置machine await sync_to_async(Machine.current, thread_sensitiveTrue)() old_config dict(machine.config or {}) config dict(old_config)Machine.current()是一个带 7 天MACHINE_RECHECK_INTERVAL 7 * 24 * 60 * 60见 machine/models.py内存缓存的类方法它按主机 GUIDget_host_guid()定位/创建当前机器的数据库记录此处通过sync_to_async(..., thread_sensitiveTrue)把它桥接到 asyncio 事件循环中调用Django ORM 是同步代码。之后以现有machine.config的副本为基底进行合并保证不丢旧键。阶段 3按事件形态分派合并策略MachineEvent有三种形态处理器分别处理事件形态触发条件处理逻辑整包配置event.config is not None用_strip_to_binary_keys(event.config)过滤出二进制键整体update进现有配置单键更新event.method update剥掉config/前缀取键名通过白名单校验后写入config[key] event.value单键删除event.method unset剥掉config/前缀取键名通过白名单校验后config.pop(key, None)其他以上皆非直接return不产生任何写入注意event.key.replace(config/, , 1)的细节事件键通常以config/作为命名空间前缀例如config/LITEPARSE_BINARY这里只替换第一次出现且替换后经.strip()去空白空键会被拦截。阶段 4幂等比较与落库if config old_config: return machine.config config await machine.asave(update_fields[config, modified_at])合并结果与旧配置完全相同时直接返回幂等避免无意义写入有变化才写回且只更新config与modified_at两个字段保持最小化写集。安全闭环事件写入 → 落库 → 镜像回文件MachineService并不是安全边界的终点。它写入的Machine.config会在三层机制下形成一个闭环事件层白名单本文核心_is_binary_event_key/_strip_to_binary_keys保证只有二进制路径与安装缓存能经由事件进入Machine.config模型层清洗_sanitize_machine_config在Machine.current()读取路径上进一步验证*_BINARY覆盖项——路径已不存在、或路径落在ABXPKG_LIB_DIR之外二进制被卸载或 lib 目录迁移的过期覆盖项会被自动清除非_BINARY键则一律透传「不是我们该过滤的」。这保证了二进制卸载后Machine.config中的残留路径不会继续生效文件镜像Machine.save()在写库成功后调用mirror_machine_config_to_file()见 config/collection.py把Machine.config全量回写到ArchiveBox.conf使两个存储 1:1 对齐启动时的sync_machine_and_file()config/collection.py则处理进程级的一次性对账双方键并集、较新一方胜出。也就是说即使某个不可信插件向事件总线灌入恶意MachineEvent它最多只能修改二进制路径/缓存这类派生数据而这些数据还会经过模型层清洗与文件层镜像的二次校验无法触及安全敏感的用户配置。在运行时中的装配位置三处实例化MachineService是一个纯事件消费者因此它必须被显式装配到具体的事件总线上才能生效。从 runner.py 可以看到它在三类运行场景中被实例化运行场景位置用途爬取运行器CrawlRunner.__init__runner.py与BinaryService、CrawlService、SnapshotService等一同注册保证爬取过程中二进制探测结果能落库二进制安装_run_binaryrunner.py先发射MachineEvent(configconfig, config_typeuser)再发射MachineEvent(configderived_config, config_typederived)runner.py由MachineService持久化 derived 部分插件安装安装流程runner.pyarchivebox install等命令装配同一套服务栈安装解析出的二进制路径事件最终写入Machine.config一个值得注意的模式是_run_binary中先发user事件、后发derived事件。user事件被MachineService忽略仅作为其他监听者的上下文而derived事件携带的machine.config派生配置才被持久化——这正好印证了阶段 1 的类型过滤逻辑在实际运行时的分工。行为验证端到端测试如何证明安全边界仓库中的 test_machine_service.py 用一段完整端到端脚本验证了本模块的全部关键行为测试流程可概括为准备运行archivebox install liteparse安装真实二进制Binary.objects.get(namelit)拿到LITEPARSE_BINARY与LITEPARSE_TESSERACT_BINARY的实际路径发射 user 事件MachineEvent(config{LITEPARSE_BINARY: /tmp/user-config-must-not-persist, CHROME_USER_DATA_DIR: /tmp/profile}, config_typeuser)发射 derived 事件MachineEvent(config{LITEPARSE_BINARY: 真实路径, LITEPARSE_TESSERACT_BINARY: 真实路径, ABX_INSTALL_CACHE: {lit: cached}, ABX_UV_CACHE: /tmp/uv-cache, CHROME_USER_DATA_DIR: /tmp/derived-profile}, config_typederived)发射 unset / update 事件methodunset, keyconfig/LITEPARSE_BINARY与methodupdate, keyconfig/LITEPARSE_BINARY断言见 test_machine_service.pymachine.config[LITEPARSE_BINARY] 真实路径derived 生效machine.config[LITEPARSE_BINARY] ! /tmp/user-config-must-not-persistuser 事件被忽略未污染配置machine.config[ABX_INSTALL_CACHE] {lit: cached}且ABX_UV_CACHE保留ABX_*_CACHE白名单规则生效注意CHROME_USER_DATA_DIR没有出现在断言中——它既不满足_BINARY后缀也不满足ABX_*_CACHE因此被_strip_to_binary_keys过滤掉了清理验证unlink()删除安装路径后再次运行archivebox versionMachine.config中残留的LITEPARSE_BINARY被_sanitize_machine_config自动清除test_machine_service.py。这套断言逐条对应本模块的三个设计目标白名单过滤user 事件被拒、derived 二进制配置持久化、以及过期路径的自动回收。与相关模块的分工总结MachineService在整个 ArchiveBox 服务层中处于一个容易被忽视但位置关键的角色。它与相邻模块的分工如下BinaryServicebinary_service.py负责二进制的安装调度是MachineEvent的生产者之一Machine模型machine/models.pyMachineService的唯一写入目标负责模型层清洗_sanitize_machine_config与保存后镜像config.collectionconfig/collection.py文件 ↔ 数据库双向镜像的实现者构成事件写入之外的受控配置通道CrawlRunner/_run_binary/ 安装流程runner.py事件总线的装配者决定MachineService何时生效。一句话概括整个数据流上游服务发射MachineEvent→MachineService按config_type过滤、按白名单清洗 → 合并写入Machine.config→ 模型清洗 → 镜像回ArchiveBox.conf。这条链路既保证了二进制探测结果在数据库中的持久可见性又以双层校验守住了用户配置文件的安全边界是理解 ArchiveBox 事件驱动架构与配置管理设计的理想入口。【免费下载链接】ArchiveBox Open source self-hosted web archiving. Takes URLs/browser history/bookmarks/Pocket/Pinboard/etc., saves HTML, JS, PDFs, media, and more...项目地址: https://gitcode.com/gh_mirrors/ar/ArchiveBox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ArchiveBox 机器服务（MachineService）源码解析：事件驱动的 Machine.config 持久化与二进制键白名单机制
ArchiveBox 机器服务MachineService源码解析事件驱动的 Machine.config 持久化与二进制键白名单机制【免费下载链接】ArchiveBox Open source self-hosted web archiving. Takes URLs/browser history/bookmarks/Pocket/Pinboard/etc., saves HTML, JS, PDFs, media, and more...项目地址: https://gitcode.com/gh_mirrors/ar/ArchiveBox导读archivebox.services.machine_service是 ArchiveBox 事件驱动架构中负责「机器Machine配置持久化」的核心服务模块。它监听 abx-dl 事件总线上的MachineEvent把与外部二进制如 Chrome、yt-dlp、tesseract 等相关的配置覆盖项写入数据库中的Machine.configJSON 字段并通过文件 ↔ 数据库双向镜像机制与ArchiveBox.conf保持一致。阅读本文后你将理解为什么Machine.config允许存放任意用户配置键却只允许事件写入二进制相关键、MachineService如何区分user与derived两类事件以及该模块与安全边界、安装流程、爬取运行时之间的完整协作链路。本文基于仓库中的 autodoc 文档 archivebox.services.machine_service 展开源码与测试证据见 machine_service.py、machine/models.py 与 test_machine_service.py。模块概览公开 API 与职责边界该模块的全部公开 API 由三个对象构成职责非常收敛——它只做一件事把MachineEvent中合法二进制相关的配置持久化到当前机器的Machine.config。API类型职责_is_binary_event_key(key: str) - bool模块级函数判断一个配置键是否属于「允许事件写入」的二进制相关键_strip_to_binary_keys(config: dict \| None) - dict模块级函数从任意配置字典中过滤出全部二进制相关键MachineService(bus)服务类继承abx_dl.services.base.BaseService订阅MachineEvent将其中的二进制配置合并写入Machine.config并落库在类层面MachineService有两个关键类属性autodoc 文档中亦有明确标注LISTENS_TO [MachineEvent]声明本服务只监听MachineEvent这一类事件EMITS []本服务不对外发出任何事件是纯消费者sink。这个「只监听、不发出」的设计说明MachineService位于事件流水线的末端扮演持久化收尾的角色上游二进制安装服务、爬取运行时通过事件总线广播配置变更由它统一负责落库从而让业务代码无需直接 import Django ORM 即可产生副作用。核心实现一_is_binary_event_key—— 事件写配置的安全白名单def _is_binary_event_key(key: str) - bool: MachineEvent projector only ever writes binary-related state. Machine.config mirrors ArchiveBox.conf so arbitrary user keys can legitimately live there — but they get there through the file ↔ DB sync, not through events. Letting events write arbitrary keys would let an untrusted plugin overwrite security-sensitive user config (the file ↔ DB mirror is a security boundary), so the projector strips anything that isnt a binary path or the binary install cache. if key.startswith(ABX_) and key.endswith(CACHE): return True return key.endswith(_BINARY)这个函数定义了事件写入配置的白名单规则只有两类键可以通过事件进入Machine.configABX_前缀 CACHE后缀的键例如ABX_INSTALL_CACHE、ABX_UV_CACHE——它们记录二进制安装缓存的状态以_BINARY结尾的键例如CHROME_BINARY、LITEPARSE_BINARY、LITEPARSE_TESSERACT_BINARY——它们记录某个外部二进制的解析路径。为什么需要这道白名单注释中揭示了其背后深刻的安全考量这是本模块设计的核心逻辑Machine.config是ArchiveBox.conf的数据库镜像因此它天生允许存放任意用户配置键BASE_URL、SERVER_SECURITY_MODE、插件开关等都可能合法地出现在其中但这些任意键是通过文件 ↔ 数据库同步而非事件进入Machine.config的这是一条受控通道事件总线是插件可编程、可注入的开放通道。如果允许事件写入任意键不可信的插件就能通过伪造MachineEvent覆盖安全敏感的用户配置例如篡改SERVER_SECURITY_MODE从而突破安全边界。因此_is_binary_event_key把事件写入能力收敛到「二进制路径 安装缓存」这个小集合。二进制路径本质上来自本机探测或安装结果属于可验证的派生数据即使被覆盖也只会影响某个外部工具的执行路径不会直接改写认证、网络、权限等安全关键配置。核心实现二_strip_to_binary_keys—— 整包配置的过滤漏斗def _strip_to_binary_keys(config: dict[str, Any] | None) - dict[str, Any]: if not isinstance(config, dict): return {} return {key: value for key, value in config.items() if _is_binary_event_key(str(key))}该函数是_is_binary_event_key的批量应用版本输入一个任意配置字典可能来自事件的config字段输出只保留二进制相关键的子集。注意两点防御性细节入参不是字典例如None时返回空字典不会抛异常键被强制转为字符串后再做判断避免非字符串键导致类型错误。在MachineService的事件处理器中这个函数是「整包合并」路径的守门人当MachineEvent.config携带一份完整配置时先经它过滤再与现有配置合并。核心实现三MachineService类与on_MachineEvent__save_to_db事件处理器类定义与订阅class MachineService(BaseService): LISTENS_TO [MachineEvent] EMITS [] def __init__(self, bus): super().__init__(bus) self.bus.on(MachineEvent, self.on_MachineEvent__save_to_db)构造函数除了初始化基类外只做一件事把on_MachineEvent__save_to_db注册为MachineEvent的处理器。这意味着只要在某个事件总线上实例化MachineService该总线上的所有MachineEvent都会自动触发持久化逻辑。事件处理器的完整流程async def on_MachineEvent__save_to_db(self, event: MachineEvent) - None: from archivebox.machine.models import Machine if event.config_type ! derived: return machine await sync_to_async(Machine.current, thread_sensitiveTrue)() old_config dict(machine.config or {}) config dict(old_config) if event.config is not None: binary_only _strip_to_binary_keys(event.config) config.update(binary_only) elif event.method update: key event.key.replace(config/, , 1).strip() if key and _is_binary_event_key(key): config[key] event.value elif event.method unset: key event.key.replace(config/, , 1).strip() if key and _is_binary_event_key(key): config.pop(key, None) else: return if config old_config: return machine.config config await machine.asave(update_fields[config, modified_at])整个处理逻辑可以拆解为四个阶段阶段 1类型过滤只看 derived 事件if event.config_type ! derived: return这是第一道也是最重要的闸门。abx-dl 事件模型中的MachineEvent带有一个config_type字段取值至少包含user与derived两类见 runner.py 中config_typeuser与config_typederived两种发射方式user事件携带用户/配置文件层面的原始配置。MachineService对其直接忽略——因为这些配置会经由文件 ↔ 数据库同步通道进入Machine.config事件通道无权染指derived事件携带运行时探测/派生出的配置二进制路径、安装缓存等。只有这类事件会被接受并持久化。阶段 2读取当前机器与现有配置machine await sync_to_async(Machine.current, thread_sensitiveTrue)() old_config dict(machine.config or {}) config dict(old_config)Machine.current()是一个带 7 天MACHINE_RECHECK_INTERVAL 7 * 24 * 60 * 60见 machine/models.py内存缓存的类方法它按主机 GUIDget_host_guid()定位/创建当前机器的数据库记录此处通过sync_to_async(..., thread_sensitiveTrue)把它桥接到 asyncio 事件循环中调用Django ORM 是同步代码。之后以现有machine.config的副本为基底进行合并保证不丢旧键。阶段 3按事件形态分派合并策略MachineEvent有三种形态处理器分别处理事件形态触发条件处理逻辑整包配置event.config is not None用_strip_to_binary_keys(event.config)过滤出二进制键整体update进现有配置单键更新event.method update剥掉config/前缀取键名通过白名单校验后写入config[key] event.value单键删除event.method unset剥掉config/前缀取键名通过白名单校验后config.pop(key, None)其他以上皆非直接return不产生任何写入注意event.key.replace(config/, , 1)的细节事件键通常以config/作为命名空间前缀例如config/LITEPARSE_BINARY这里只替换第一次出现且替换后经.strip()去空白空键会被拦截。阶段 4幂等比较与落库if config old_config: return machine.config config await machine.asave(update_fields[config, modified_at])合并结果与旧配置完全相同时直接返回幂等避免无意义写入有变化才写回且只更新config与modified_at两个字段保持最小化写集。安全闭环事件写入 → 落库 → 镜像回文件MachineService并不是安全边界的终点。它写入的Machine.config会在三层机制下形成一个闭环事件层白名单本文核心_is_binary_event_key/_strip_to_binary_keys保证只有二进制路径与安装缓存能经由事件进入Machine.config模型层清洗_sanitize_machine_config在Machine.current()读取路径上进一步验证*_BINARY覆盖项——路径已不存在、或路径落在ABXPKG_LIB_DIR之外二进制被卸载或 lib 目录迁移的过期覆盖项会被自动清除非_BINARY键则一律透传「不是我们该过滤的」。这保证了二进制卸载后Machine.config中的残留路径不会继续生效文件镜像Machine.save()在写库成功后调用mirror_machine_config_to_file()见 config/collection.py把Machine.config全量回写到ArchiveBox.conf使两个存储 1:1 对齐启动时的sync_machine_and_file()config/collection.py则处理进程级的一次性对账双方键并集、较新一方胜出。也就是说即使某个不可信插件向事件总线灌入恶意MachineEvent它最多只能修改二进制路径/缓存这类派生数据而这些数据还会经过模型层清洗与文件层镜像的二次校验无法触及安全敏感的用户配置。在运行时中的装配位置三处实例化MachineService是一个纯事件消费者因此它必须被显式装配到具体的事件总线上才能生效。从 runner.py 可以看到它在三类运行场景中被实例化运行场景位置用途爬取运行器CrawlRunner.__init__runner.py与BinaryService、CrawlService、SnapshotService等一同注册保证爬取过程中二进制探测结果能落库二进制安装_run_binaryrunner.py先发射MachineEvent(configconfig, config_typeuser)再发射MachineEvent(configderived_config, config_typederived)runner.py由MachineService持久化 derived 部分插件安装安装流程runner.pyarchivebox install等命令装配同一套服务栈安装解析出的二进制路径事件最终写入Machine.config一个值得注意的模式是_run_binary中先发user事件、后发derived事件。user事件被MachineService忽略仅作为其他监听者的上下文而derived事件携带的machine.config派生配置才被持久化——这正好印证了阶段 1 的类型过滤逻辑在实际运行时的分工。行为验证端到端测试如何证明安全边界仓库中的 test_machine_service.py 用一段完整端到端脚本验证了本模块的全部关键行为测试流程可概括为准备运行archivebox install liteparse安装真实二进制Binary.objects.get(namelit)拿到LITEPARSE_BINARY与LITEPARSE_TESSERACT_BINARY的实际路径发射 user 事件MachineEvent(config{LITEPARSE_BINARY: /tmp/user-config-must-not-persist, CHROME_USER_DATA_DIR: /tmp/profile}, config_typeuser)发射 derived 事件MachineEvent(config{LITEPARSE_BINARY: 真实路径, LITEPARSE_TESSERACT_BINARY: 真实路径, ABX_INSTALL_CACHE: {lit: cached}, ABX_UV_CACHE: /tmp/uv-cache, CHROME_USER_DATA_DIR: /tmp/derived-profile}, config_typederived)发射 unset / update 事件methodunset, keyconfig/LITEPARSE_BINARY与methodupdate, keyconfig/LITEPARSE_BINARY断言见 test_machine_service.pymachine.config[LITEPARSE_BINARY] 真实路径derived 生效machine.config[LITEPARSE_BINARY] ! /tmp/user-config-must-not-persistuser 事件被忽略未污染配置machine.config[ABX_INSTALL_CACHE] {lit: cached}且ABX_UV_CACHE保留ABX_*_CACHE白名单规则生效注意CHROME_USER_DATA_DIR没有出现在断言中——它既不满足_BINARY后缀也不满足ABX_*_CACHE因此被_strip_to_binary_keys过滤掉了清理验证unlink()删除安装路径后再次运行archivebox versionMachine.config中残留的LITEPARSE_BINARY被_sanitize_machine_config自动清除test_machine_service.py。这套断言逐条对应本模块的三个设计目标白名单过滤user 事件被拒、derived 二进制配置持久化、以及过期路径的自动回收。与相关模块的分工总结MachineService在整个 ArchiveBox 服务层中处于一个容易被忽视但位置关键的角色。它与相邻模块的分工如下BinaryServicebinary_service.py负责二进制的安装调度是MachineEvent的生产者之一Machine模型machine/models.pyMachineService的唯一写入目标负责模型层清洗_sanitize_machine_config与保存后镜像config.collectionconfig/collection.py文件 ↔ 数据库双向镜像的实现者构成事件写入之外的受控配置通道CrawlRunner/_run_binary/ 安装流程runner.py事件总线的装配者决定MachineService何时生效。一句话概括整个数据流上游服务发射MachineEvent→MachineService按config_type过滤、按白名单清洗 → 合并写入Machine.config→ 模型清洗 → 镜像回ArchiveBox.conf。这条链路既保证了二进制探测结果在数据库中的持久可见性又以双层校验守住了用户配置文件的安全边界是理解 ArchiveBox 事件驱动架构与配置管理设计的理想入口。【免费下载链接】ArchiveBox Open source self-hosted web archiving. Takes URLs/browser history/bookmarks/Pocket/Pinboard/etc., saves HTML, JS, PDFs, media, and more...项目地址: https://gitcode.com/gh_mirrors/ar/ArchiveBox创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考