你想解决什么问题
webhook(`/wf1/api/hooks/`)是对外触发工作流的标准入口——外部调度器、自动化平台、其他系统的集成都走它。当前协议面有三处薄弱,制约公网部署和机器对机器对接:
- 仅 token 明文比对(query / Bearer / X-Hook-Token 三种携带方式)。无签名机制与密钥轮换,token 泄漏即可任意重放;query 携带的 token 还会落入中间层访问日志
- 无幂等保护:网络层超时重试、调度器重复触发都会各自起一个并发 run(多运行并发本身是产品能力,这里缺的是给触发方的幂等控制手段)
- 拿不到完成事件:触发方想知道结果只能轮询 `GET /runs/detail`;n8n 这类节点式集成期望「触发了就等回调」
你的设想
全部做成可选能力,三项向后兼容:
- 签名:每个 hook 可配 signing secret;请求头 `X-WF1-Signature: sha256=`(HMAC-SHA256 覆盖 body + 时间戳),时间窗外拒绝防重放。纯 token 校验保持不变
- 幂等:接受 `Idempotency-Key` 头(或 body 字段),窗口内重复 key 直接返回首次 runId 不再起新 run
- 完成回调:hook 可选配 callbackUrl;运行终态(success/error/canceled)时 POST JSON(runId / status / 工作流名 / 结果摘要截断)
约束
- 未配置 secret / key / callback 的存量 hook 行为零变化
- 回调发送失败只记日志/hook 元数据,绝不影响业务运行状态(与通知失败隔离同款约定)
- 全部走插件自有路由,不碰官方特权面
你想解决什么问题
webhook(`/wf1/api/hooks/`)是对外触发工作流的标准入口——外部调度器、自动化平台、其他系统的集成都走它。当前协议面有三处薄弱,制约公网部署和机器对机器对接:
你的设想
全部做成可选能力,三项向后兼容:
约束