不用后端也能验证

一个 Caputchin 令牌在有东西确认它之前什么都证明不了。通常那个东西是 你自己的后端，它调用 /siteverify 并决定是否信任该请求。托管验证把那一步挪到 Caputchin 上：你的表单提交到一个 Caputchin 转发器，Caputchin 核验令牌、丢弃任何失败的、并只把已核验的提交转发到一个你选定的目标。

它和后端检查是同一个信任决定，只是在 Caputchin 这一侧、而非你这一侧运行。要点是没有 /siteverify 调用要写，也没有密钥要留在一台服务器上，因为根本没有服务器。

托管验证是一个付费功能，在 Alpha 及以上可用。

它给谁用

托管验证的存在，是为了那种“仅仅为了核验一个令牌就跑一个后端”超出项目所需的情况。

如果你确实跑一个后端、并想在那里核验，那就改用 在你的后端核验。两者是互斥的选择，而非叠加的层。

它如何运作

转发器只在投递它所花的那一瞬间把提交保留在内存里。提交和投递之间没有存储，而 caputchin-token 字段在载荷到达你的目标之前就被剥离。

目标

你按站点密钥配置其中一个或两个。两个都启用是一种常见套路：发到一个 webhook 做处理，再给自己邮一份副本。

投递不签名。转发器 URL 的保密性即为一个 webhook 调用的身份验证，所以把这个 URL 留在公开仓库和客户端代码之外。设置教程 展示确切的 webhook 载荷。

什么被保密

托管验证遵循和 Caputchin 其余部分同样的无访客数据姿态：

• 提交从不被存储。 它们在转发期间存活于进程内存里，然后就没了。如果你想要一份记录，就在 webhook 那一端建你自己的。
• 不采集关于提交者的任何数据。 无 IP、无 User-Agent、无指纹、无追踪。
• 遥测仅为聚合。 Caputchin 计数投递的成功和失败，好让你看到你的目标是否健康，而绝不计数任何提交的内容。见 统计。

一个客户提供的 URL 如何被保障安全

一个 Caputchin 的服务器将会调用的 URL，是一个典型的服务端请求伪造风险。转发器会拒绝任何主机是私有、回环、链路本地或云元数据地址的 webhook URL，在你保存它时拒绝，并在每次投递之前再次拒绝。被阻止的类别包括：

那些试图伪装一个被阻止地址的编码也会被逮住：一个十进制整数主机如 http://2130706433/，或一个十六进制主机如 http://0x7f000001/（两者都意为 127.0.0.1），都会被拒绝。只接受 http 和 https URL；任何其他协议都被拒。转发器还拒绝跟随重定向，所以一个 webhook 端点无法把调用弹到一个内部目标上。一个被阻止的 URL 以一个通用错误、而非一个具体错误的形式浮现，所以它无法被用来探测一个网络。因此你的 webhook 必须住在一个公开的 https URL 上。

什么被有意略去

• 没有提交收件箱。 没有存储的提交历史可供在仪表盘里浏览。
• 没有第一方的 Discord、Slack、Telegram 或 SMS 适配器。 只有 webhook 和邮件。一个 webhook 可以在你这一侧扇出到那些里的任何一个。
• 没有文件上传。 转发器接受文本字段；一个携带文件的提交会被拒绝。
• 没有载荷变换。 表单提交什么，你的目标就收到什么，外加验证元数据。

另见

• 设置托管验证：一篇先把它接到一个测试收件箱的演练。
• 托管验证统计：读投递健康度。
• 在你的后端核验：当你确实跑一台服务器时的那个替代方案。