TREK 插件管理面板实战指南:装、审、更、撤,四步管好第三方代码

TREK 插件管理面板实战指南:装、审、更、撤,四步管好第三方代码 TREK 插件管理面板实战指南装、审、更、撤四步管好第三方代码【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREKTREK 插件管理面板Admin → Plugins是自托管管理员治理第三方代码的总入口。读完本文你能独立完成一次规范的 TREK 插件安装从注册表发现候选、通过预安装审查对话框核对权限与出口主机、处理版本不兼容的回退逻辑到批准更新、应对签名换钥被锁、最后干净地下线一个插件。 先建立信任链代码从哪来到哪儿为止在动手之前先把整条链路在脑子里过一遍后面所有操作才有落点。插件代码的来源只有三种官方注册表、你自己上传的压缩包、本地开发目录的符号链接。无论走哪条路TREK 都按同一个顺序建立信任先校验字节注册表安装走 SHA-256 校验旁路上传因没有注册表条目而跳过分量再校验作者身份Ed25519 签名 首次安装时 TOFU 钉住公钥然后安装完成时插件仍默认处于关闭状态——下载、安全解压、重验 manifest、登记 inactive全程不执行一行第三方代码。只有你手动拨下启用开关plugin-runtime.service.ts 才会拉起一个独立 OS 子进程用 Node 权限模型--permission把文件系统读取限定在插件自己的代码目录里。一句话先证明它是谁发的再允许它跑起来跑起来也只给最小沙箱。搞清楚这条链之后我们把日常运维拆成三个真实场景装第一个插件、插件发新版、下线插件。 场景一如何给生产实例装第一个插件前提是你已经是管理员且插件运行时处于开启状态默认开启判定逻辑见 kill-switch.ts。运行时关闭时面板只会提示The plugin runtime is turned off (TREK_PLUGINS_ENABLED)...任何安装动作都会被拒绝并返回 503。第一步在 Discover 视图挑候选。每张卡片展示作者、类型Widget / Page / Integration / Trip page、最新版本号、下载量以及 Reviewed / Signed 徽章。注意 Discover 数据有 30 分钟服务端缓存registry.service.ts 中CACHE_TTL 30 * 60 * 1000如果你刚发布插件却看不到点工具栏的Rescan即可强制拉取聚合索引dist/index.json跳过缓存和 CDN 延迟。第二步点开卡片读预安装审查对话框。这一步是 TREK 插件安全审查的核心。对话框内容不是作者写的营销文案而是服务端拉取插件审查提交点的实时 manifest 生成的ManifestPreviewWhat it can access——请求的权限逐条翻译成平实语言如读取行程创建和编辑地点Connects to——所有声明的出口主机等宽字体 chip 展示Setup——插件要你或每个用户填的配置项标注 Instance-wide / Per user / RequiredDetails——版本、体积、要求的 TREK 版本范围、审查时间、总下载量。若插件声明了operatorEgress即连接一个只有你知道地址的自托管服务如 Gotify / ntfy会额外出现 hosts you add提示安装后需到⋯ → Allowed hosts逐个补填主机名补填前该插件一行会挂着琥珀色Add allowed host徽标——意思是它此刻一个外部主机都够不到。第三步点 Install注意按钮的两种回退。如果最新版要求的 TREK 版本比你新情形按钮表现存在仍兼容当前宿主的旧版本变为Install {version}直接装那个旧版本没有任何版本兼容变为Incompatible并禁用琥珀色提示条说明原因版本匹配由 host-compat.ts 的assertHostCompatible/hostSatisfies在服务端兜底前端按钮只是它的镜像。装完后插件是Off状态不会运行任何代码。第四步激活。拨下Enable plugin开关时服务端assertActivatable按版本兼容 → 权限再同意 → 必需 addon → 插件依赖的顺序做只读预检任何一项失败都不会留下半激活状态。常见拒绝码错误码含义补救ADDON_DISABLED依赖的 addon 被关到 Admin → Addons 打开后重试DEPENDENCY_MISSING依赖插件缺失或版本过旧对话框逐条列出一键 Download / Update 后自动重试TREK_VERSION_INCOMPATIBLE/TREK_VERSION_UNKNOWN宿主版本不匹配或未声明范围升级 TREK 或等作者声明依赖缺失时对话框提供的下载会自动先拉起全部依赖再启用目标enableOrder拓扑排序被顺带打开的依赖有 toast 告知。装完激活场景一结束。但注册表是活的——下面讲代码变新了怎么办。 场景二插件发新版后怎么处理行上出现Update → v{version}按钮、列表上方提示N 个插件可更新时先分清两种更新路径。透明更新无需你做任何事新版本声明的权限与出口主机没有超出已授予范围时plugin-runtime.service.ts 的update()直接透明重启到新代码。注意resolveUpdateTarget挑的是当前 TREK 能跑的最新版本而非无脑取最高版本——避免新版放弃对老宿主的支持时把一个正常工作的插件更新坏。新权限需批准若新版请求了未授予的权限或新的出站连接TREK 会先落盘新代码但保持插件关闭弹窗列出Newly requested permissions与New outbound connections由你选择Approve turn on或Keep off for now。批量更新时这类同意框排队依次出现一个都不会跳过。若被批准的新版本未签名对话框会补一句没有任何机制把该版本与其作者绑定。记住铁律更新永远不会静默扩大权限差集不为空就必然停下来等你点头。签名换钥导致更新被锁怎么办当作者提供的签名密钥与安装时钉住的密钥不一致更新被拒行上显示Update blocked和Review入口对话框并排展示钉住密钥与新密钥的指纹原文提示TREK cannot tell a legitimate key rotation apart from a takeover — both look identical from here. Confirm the new key with the author through a channel you already trust before you accept it.—— 来源wiki/Plugins.md此时唯一合法的覆盖路径是Trust the new key update。服务端在/retrust端点plugins.controller.ts 的POST :id/retrust做了双重约束只有错误码为SIGNATURE_KEY_CHANGED才允许覆盖RETRUSTABLE_CODE见 signature-status.ts签名缺失SIGNATURE_MISSING、无效SIGNATURE_INVALID、半声明SIGNATURE_INCOMPLETE一律没有覆盖按钮服务端同样拒绝——这些情形下字节根本对不上作者签过的内容放行没有正当理由调用方必须回显对话框中展示的完整公钥而非截断指纹防止渲染后注册表条目又被换钥重信任与更新在同一调用内原子完成要么新密钥验证通过、插件落版并钉住新钥要么一切不变不存在钉住未验证密钥的中间窗口。签名与更新讲完下一个问题是代码要彻底离开实例时的流程。 场景三如何安全下线一个插件下线分两步走先停用可逆再卸载不可逆。停用与级联。关闭一个插件开关时deactivateWithDependents会顺带停用所有传递依赖它的插件——一个插件不能在依赖缺失的情况下继续跑。反向同理某 addon 被管理员关闭时deactivateForDisabledAddon会级联停用依赖它的全部插件。所以停用一个底层插件前先看一眼还有谁依赖它。卸载时到底删了什么⋯ → Delete的确认框原文写着This stops the plugin, removes its code, and deletes all of its data. This cannot be undone.来源wiki/Plugins.md。执行清单无条件删除插件进程停止、代码目录移除、plugins注册表行与设置字段、出口主机白名单、定时任务。这两项无条件清掉的用意很明确——否则日后复用同一 id 的新插件会悄悄继承前人的出口权限或让一条指向已不存在插件的定时回调继续触发勾选删除数据时额外清除插件私有数据目录、错误日志、实体元数据、每用户配置含加密的 API 密钥、OAuth 令牌与状态、迁移台账、能力审计日志、待处理的 GDPR 擦除队列;选择保留数据时数据目录与 GDPR 擦除队列刻意保留——目录里可能还躺着已注销用户的行擦除义务必须跟着存活等同一 id 插件重装后继续兑现。另有一条容易忽略的路径用相同 id 覆盖上传旁路插件时旧代码会被先强制停止并停用不存在换了壳但旧代码还在跑的状态。下线流程到此闭环。最后把散落的规则收拢成一张安全边界总账。️ 安全边界隔离模型与徽章的真实含义前面每个环节都在为这条边界服务值得单独过一遍。子进程隔离。每个活动插件跑在独立 OS 子进程里Node 以--permission启动文件系统读取限定其自身代码目录。它物理上拿不到JWT_SECRET、数据库连接串、trek.db不能写文件、不能派生子进程、不能用 worker 线程、不能加载原生模块它自己的数据存在独立 SQLite 中且只有 TREK 能代为读写。插件崩溃、挂起、内存耗尽死的只有它自己的进程宿主继续运转并可以重启或停用它。能力 RPC 是封死的通道。插件只通过内部 RPC 与 TREK 通信宿主只应答 manifest 声明且你已批准的能力未授予的调用被拒绝而非忽略。更关键的是即便插件代码跑在 fork 出来的进程里其原始 IPC 原语process.send、process.on(message)在代码加载前就已被吊销——它既伪造不了宿主消息也窃听不了其他在途请求一切交互被迫经过能力校验的 SDK。插件页面/组件则运行在密封的浏览器 frame 中读不到会话 cookie也碰不到外围 TREK 页面。出口白名单为何保存后必须重启出口守卫在子进程初始化时安装一次且拒绝二次init——运行中进程的白名单无法热扩容。所以你保存 Allowed hosts 的实际后果是插件会重启一次新列表随新进程生效删除某个主机后插件同样立即失去该出口并重启。主机名本身的格式校验与 manifest 声明出口的规则一致不允许裸*、不允许整 TLD 通配、不允许带协议前缀。私网出口开关的风险。若插件要连的服务就在本机或同一局域网localhost、192.168.x.x需设TREK_PLUGIN_ALLOW_PRIVATE_EGRESSon。但此变量放宽的是所有已安装插件的私网出口策略只有你信任每一个插件时才该开启。另外两条硬边界未声明operatorEgress的插件永远无法被授予任何主机只有管理员能添加主机普通用户即使自带凭据也不能扩大出口。徽章对照表保证什么、不保证什么。徽章保证不保证ReviewedTREK 维护者对该版本做过恶意软件扫描质量、可用性、无害Signed字节与作者签名密钥匹配TOFU 钉住代码的意图Unsigned字节与注册表担保一致与作者的绑定关系少一层保证非危险信号Sideloaded与注册表相同的解压/manifest 硬防护无签名、无扫描——没有人为其背书Dev-Link仅开发环境可用的本地符号链接同上且未经任何外部审查两个必须反复强调的结论徽章不说明代码做了什么——被允许读行程且能连某主机的插件完全可能把行程数据发过去所以安装前一定先读权限与出口清单而 Sideloaded / Dev-Link 只是来源标签旁路插件以声明权限原样运行不享受额外沙箱也不被额外限制。权限的具体授予范围如只读db:read:trips每次调用都校验 membership、notify:send收件人被强制限定为操作者本人或所属行程在 wiki/Plugin-Permissions.md 中逐条记录。边界清楚了剩下的是把四个环境变量记进你的部署清单。 环境变量速查表变量作用默认值TREK_PLUGINS_ENABLED插件系统总开关仅false/0/off/no大小写不敏感判定为关每次调用实时读取改后重启生效关闭时已装插件留盘停用开启TREK_PLUGINS_DEV_LINK允许从本地构建目录注册插件并热重载符号链接 fs.watch重建后防抖 400ms 重新 fork仅当值恰为1时Link a local plugin入口才出现关闭TREK_PLUGIN_ALLOW_PRIVATE_EGRESS设为on允许插件访问私网/内网地址会放宽所有插件谨慎开启关闭拒绝私网出口TREK_PLUGIN_REGISTRY_URL覆盖 Discover 页浏览的注册表索引地址可指向自己的 fork/镜像TREK 官方注册表关闭整个系统的最小改动environment: - TREK_PLUGINS_ENABLEDfalse上传插件的体积上限是 50 MB服务端按50 * 1024 * 1024 4096截断超出直接拒绝。变量记住了最后把全部要点压缩成两张可直接勾选的清单贴在值班手册里。✅ 安装前 / 更新前自查清单安装前每个新插件我读过 What it can access 里每一条权限的平实语言描述我核对过 Connects to 的每个出口主机都是应该出现的若插件带operatorEgress我已知晓需事后手动补填 Allowed hosts且补填前它连不出任何主机徽章状态Reviewed / Signed / Sideloaded与我愿意承担的风险匹配版本不兼容时我确认安装的是回退的兼容旧版而非硬装最新版若插件连局域网服务我确认TREK_PLUGIN_ALLOW_PRIVATE_EGRESS的必要性与影响范围安装后插件保持 Off我计划在激活前再确认一次 addon 依赖已启用更新前每个新版本我分清这是透明更新还是新权限更新若是后者我逐条读过 Newly requested permissions 与 New outbound connections批量更新时我确认每个同意框都逐一处理而非跳过若被批准的新版未签名我接受版本与作者无绑定这一事实若出现 Update blocked我确认错误码是SIGNATURE_KEY_CHANGED才考虑覆盖覆盖前我已通过信任渠道向作者核实新密钥并在对话框中完整回显公钥我理解签名缺失/无效/半声明没有、也绝不会有覆盖入口按这张清单走完TREK 插件安装与TREK 插件权限配置就不再是点按钮而是一套可审计的治理动作——每个用户仍可在 Settings → Plugins 的活动日志里无管理员门槛地查看插件以其名义执行的每一次读取、写入与出站调用。【免费下载链接】TREKA self-hosted travel/trip planner with real-time collaboration, interactive maps, PWA support, SSO, budgets, packing lists, and more.项目地址: https://gitcode.com/GitHub_Trending/nomad22/TREK创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考