通过 RPC Service Binding 让其他 Worker 增强 Cloudflare 临时邮箱：验证码自动解析实战

通过 RPC Service Binding 让其他 Worker 增强 Cloudflare 临时邮箱验证码自动解析实战【免费下载链接】cloudflare_temp_emailCloudFlare free temp domain email 免费收发 临时域名邮箱 支持附件 IMAP SMTP TelegramBot项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare_temp_email本篇指南讲解如何在 cloudflare_temp_email 临时邮箱服务之上通过 Cloudflare Workers 的 RPC Service Binding 接入另一个 Worker例如 auth-inbox 这类 AI 验证码解析服务让外部 Worker 在邮件落库、Webhook 触发之后以 RPC 方式接力处理邮件正文、提取验证码与激活链接。读完本文你将掌握被调用 Worker 的WorkerEntrypoint改造方法、wrangler.toml与 Dashboard 两种绑定方式、ENABLE_ANOTHER_WORKER/ANOTHER_WORKER_LIST环境变量的完整语义以及如何基于源码验证整条触发链路。功能定位临时邮箱的第二大脑临时邮箱的核心能力是邮件管理接收、存储、解析与转发而**另一个 Worker 增强Another Worker Enhancement**是在此基础上开放给外部 Worker 的扩展点。最典型的场景是接入 AI 验证码解析服务由外部 Worker 自动从邮件正文中解析出验证码、激活码或激活链接并展示在独立的面板上用户无需打开邮件正文即可完成账号注册/激活流程。该功能有三个关键特性需要先行明确被动触发临时邮箱服务本身不发起业务仅在收到邮件时按规则调用外部 Worker执行时机靠后触发发生在 Webhook 之后位于整条邮件处理链路的末端依赖 RPC被调用的 Worker 必须通过 Cloudflare 的 Service Bindings RPC 机制暴露可调用方法即该 Worker 的默认导出类需要继承WorkerEntrypoint。从源码看这一执行顺序非常清晰。在 worker/src/email/index.ts 的email()入口函数中完整处理链路依次为黑名单检查 → 垃圾邮件检查 → 未知地址检查 → 附件处理 → 原始邮件入库 → 转发 → AI 内容提取 → Telegram 推送 →Webhook 触发→另一个 Worker 触发→ 自动回复。triggerAnotherWorker的调用点worker/src/email/index.ts#L107-L120明确位于triggerWebhook之后与文档executes after webhook的描述一致。第一步创建一个可被 RPC 调用的 Worker将普通 Worker 改造成 WorkerEntrypoint默认情况下Cloudflare Worker 的默认导出是一个fetch函数参数为(request, env, ctx)。要作为被调用方提供 RPC 方法必须将默认导出改为一个继承自WorkerEntrypoint的类此时fetch(request)只接收一个参数环境变量通过this.env获取执行上下文通过this.ctx获取类上的任意 public 方法如rpcEmail都会自动暴露为可被其他 Worker 通过 Service Binding 调用的 RPC 方法原先的邮件路由处理器email(message, env, ctx)同样可以保留为类方法参数变为email(message)。以下是一个完整的被调用方示例以 auth-inbox 的 AI 验证码解析为用例import { WorkerEntrypoint } from cloudflare:workers; interface Env { DB: D1Database; // ... } export default class extends WorkerEntrypointEnv { async fetch(request: Request): PromiseResponse { console.log(Original fetch interface parameter is request,env,ctx); console.log(After modifying to WorkerEntrypoint style, theres only one parameter request, getting environment variables and context has slight changes); // Environment variable and context changes see: // https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/rpc/#bindings-env // https://developers.cloudflare.com/workers/runtime-apis/bindings/service-bindings/rpc/#lifecycle-methods-ctx const env: Env this.env; const ctx: ExecutionContext this.ctx; console.log(Subsequent logic remains unchanged); return new Response(ok, { status: 200 }); } // 处理 Email Routing 转发过来的邮件 async email(message: ForwardableEmailMessage): Promisevoid { console.log(Original fetch interface parameter is message,env,ctx); console.log(After modifying to WorkerEntrypoint style, theres only one parameter message, getting environment variables and context is the same as fetch method); const env: Env this.env; const ctx: ExecutionContext this.ctx; console.log(After receiving email routing request, subsequent logic remains unchanged); } // 暴露给临时邮箱服务cloudflare_temp_email调用的 RPC 接口 async rpcEmail(requestBody: string): Promisevoid { console.log(Received request from another worker (temporary email service cloudflare_temp_email), request body: ${requestBody}); // requestBody 为 JSON 字符串由临时邮箱服务发送结构如下 // type RPCEmailMessage { // from: string | undefined | null, // to: string | undefined | null, // rawEmail: string | undefined | null, // headers: Mapstring, string, // } // ... todo: 在此处调用 AI 模型解析验证码 / 激活链接 ... } }注意rpcEmail接收的requestBody是JSON 字符串而非对象这一点与 RPC 调用方的实现细节有关详见下文触发链路源码级解析一节。RPCEmailMessage的结构在仓库中亦有对应类型定义见 worker/src/types.d.ts#L159-L164包含from发件人、to收件人、rawEmail原始邮件全文、headers邮件头四个字段。部署该 Worker完成改造后或直接使用已经改造好的 auth-inbox 派生项目将代码部署为 Cloudflare Worker 并记下 Worker 名称。该名称将用于后续的 Service Binding 配置。第二步为临时邮箱服务绑定目标 WorkerService Binding要让临时邮箱服务能够调用外部 Worker必须先在临时邮箱服务这一侧建立 Service Binding。Cloudflare 提供两种配置途径二者等价可任选其一。方式一通过 wrangler.toml 配置在临时邮箱服务的wrangler.toml中添加[[services]]段[[services]] binding AUTH_INBOX service auth-inboxbinding绑定变量名可自定义为任意字符串本示例为AUTH_INBOX后续ANOTHER_WORKER_LIST中的binding字段必须与之完全一致service上一步部署的、提供 RPC 方法调用的 Worker 名称本示例为auth-inbox。该写法与仓库模板一致见 worker/wrangler.toml.template#L196-L199模板中以注释形式给出binding AUTH_INBOX/service auth-inbox的示例。方式二通过 Dashboard 界面配置在 Cloudflare Dashboard 的临时邮箱 Worker 页面中进入Settings设置→ Bindings绑定点击添加绑定并选择Service Binding服务绑定变量名Variable name填写自定义名称可为任意字符串例如AUTH_INBOX服务Service选择上一步创建的 Worker例如auth-inbox。第三步配置环境变量启用增强功能Service Binding 只解决了能调的问题还需要通过两个环境变量告诉临时邮箱服务何时调、调哪个方法。通过 wrangler.toml 配置ENABLE_ANOTHER_WORKER true ANOTHER_WORKER_LIST [ { binding:AUTH_INBOX, method:rpcEmail, keywords:[ 验证码,激活码,激活链接,确认链接,验证邮箱,确认邮件,账号激活,邮件验证,账户确认,安全码,认证码,安全验证,登陆码,确认码,启用账户,激活账户,账号验证,注册确认, account,activation,verify,verification,activate,confirmation,email,code,validate,registration,login,code,expire,confirm ] } ] 模板中同样保留了这段配置的完整注释示例见 worker/wrangler.toml.template#L159-L172。参数说明参数是否必填默认值说明ENABLE_ANOTHER_WORKER是false总开关。默认关闭设为true才允许其他 Worker 处理邮件ANOTHER_WORKER_LIST是空JSON 数组数组内每个对象描述一个要调用的 Worker包含 3 个字段binding必填无必须与[[services]]段中指定的binding XXX完全一致示例中为AUTH_INBOXmethod可选rpcEmail调用该 Worker 的哪个 RPC 方法来处理邮件keywords可选空数组关键词数组不区分大小写。用于过滤当解析出的邮件正文文本命中这些关键词时才触发该 Worker 并调用其method方法通过 Dashboard 界面配置在Settings设置→ Environment Variables环境变量中新增两个变量ENABLE_ANOTHER_WORKER值为trueANOTHER_WORKER_LIST值为上述 JSON 数组字符串。[ { binding:AUTH_INBOX, method:rpcEmail, keywords:[ 验证码,激活码,激活链接,确认链接,验证邮箱,确认邮件,账号激活,邮件验证,账户确认,安全码,认证码,安全验证,登陆码,确认码,启用账户,激活账户,账号验证,注册确认, account,activation,verify,verification,activate,confirmation,email,code,validate,registration,login,code,expire,confirm ] } ]值得一提的是ANOTHER_WORKER_LIST在代码层面被定义为string | AnotherWorker[]联合类型见 worker/src/types.d.ts#L81-L82即既支持 JSON 字符串也支持直接传入数组。配置解析逻辑位于 worker/src/utils.ts#L280-L294 的getAnotherWorkerList()若变量为空直接返回空数组若非数组则尝试JSON.parse解析失败会打印错误并回退为空数组。因此JSON 格式书写错误会导致该功能静默失效配置后务必检查控制台日志。另外管理员后台的 Worker 配置页也会同步展示这两个设置项见 worker/src/admin_api/worker_config.ts#L61-L62。触发链路源码级解析理解触发细节有助于排查配置了但不生效的问题。核心逻辑位于 worker/src/common.ts#L923-L972 的triggerAnotherWorker()函数其执行步骤与对应规则如下正文为空直接跳过若解析出的邮件纯文本parsedText为空函数直接返回。对应邮件处理链路中先调用commonParseMail提取text再作为入参传入见 worker/src/email/index.ts#L109-L117。总开关与列表检查ENABLE_ANOTHER_WORKER不为true或ANOTHER_WORKER_LIST为空数组时直接返回。逐个 Worker 匹配对列表中的每个配置项取出keywords、binding、method缺省为rpcEmail。绑定解析通过(c.env as any)[bindingName]从环境变量中取出 Service Binding 对象再取binding[methodName]若该方法不存在或不是函数则打印method xxx not found or not function并跳过。这说明binding字段若与[[services]]中定义不一致将在这里静默跳过。关键词过滤将邮件正文整体转为小写与每个关键词做includes子串匹配关键词同样转小写实现不区分大小写的包含式匹配若无任何关键词命中打印worker.binding xxx not match keywords并跳过。需要特别留意关键词是包含式子串匹配而非精确匹配所以单个中文词如验证码即可覆盖您的验证码是这类句子同时keywords为空数组时some()恒为false该 Worker 将永远不会被触发。构造请求体并调用将RPCEmailMessage展开复制若headers是Headers类型具备forEach方法则转换为普通对象最后JSON.stringify成字符串await method(requestBody)调用外部 Worker 的 RPC 方法并打印exec worker , binding xxx , requestBody ...。单个 Worker 调用失败会捕获异常并打印execute method xxx error不会影响其他 Worker 或主流程。由此可以推断两条实用的排查思路其一日志中的not match keywords/not found or not function/exec worker三类输出分别对应没命中关键词、绑定名或方法名错误、调用成功三种状态可直接据此判断配置问题出在哪一环其二被调用方收到的requestBody永远是 JSON 字符串因此rpcEmail(requestBody: string)内部必须先JSON.parse才能拿到结构化数据。第四步测试与验证配置完成后向临时邮箱任意地址发送一封包含关键词如验证码的测试邮件然后从两个角度验证Worker 日志在临时邮箱服务与 auth-inbox Worker 的日志面板中观察是否出现exec worker , binding AUTH_INBOX以及Received request from another worker ...等输出业务结果打开 auth-inbox 提供的验证码展示面板确认邮件列表中出现解析出的验证码或激活链接。小结与注意事项最后归纳几条实战要点被调用 Worker 必须extends WorkerEntrypointRPC 方法写在类上fetch/email中的env、ctx改由this.env、this.ctx获取[[services]]的binding与ANOTHER_WORKER_LIST中的binding必须完全一致method必须是被调用 Worker 类上真实存在的方法缺省rpcEmailENABLE_ANOTHER_WORKER默认关闭ANOTHER_WORKER_LIST必须是合法 JSON 数组解析失败会静默回退为空列表关键词匹配发生在解析出的邮件纯文本上为大小写不敏感的子串匹配建议同时覆盖中英文关键词如示例中的验证码与code、verify等触发时机在 Webhook 之后属于邮件处理链路的末端增强不影响邮件存储、转发、AI 提取等前置能力。借助这一扩展点临时邮箱服务可以在不修改核心代码的前提下与任意 AI 解析、风控、归档等外部 Worker 组合形成可插拔的邮件自动化能力。【免费下载链接】cloudflare_temp_emailCloudFlare free temp domain email 免费收发 临时域名邮箱 支持附件 IMAP SMTP TelegramBot项目地址: https://gitcode.com/GitHub_Trending/cl/cloudflare_temp_email创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考