バックエンドなしで検証する
Caputchin のトークンは、何かがそれを確認するまで何も証明しません。通常その何かは あなた自身のバックエンド で、それは /siteverify を呼んでリクエストを信頼するか決めます。ホスト型認証はそのステップを Caputchin に移します。あなたのフォームが Caputchin のフォワーダーへポストし、Caputchin がトークンを検証し、失敗するものは捨て、検証済みの送信だけをあなたが選ぶ宛先へ転送します。
それはバックエンドの確認と同じ信頼の判断を、あなたの側ではなく Caputchin 側で走らせたものです。要点は、書くべき /siteverify 呼び出しがなく、サーバーに保つべきシークレットもないことです。サーバーがないからです。
ホスト型認証は有料機能で、Alpha 以上で使えます。
誰のためのものか
ホスト型認証は、トークンを確認するためだけにバックエンドを動かすのが、プロジェクトに必要な以上である場合のために存在します。
| あなたは | なぜ合うか |
|---|---|
| 静的サイト（Webflow、Framer、CDN 上の素の HTML） | フォームを受け取る、または /siteverify を呼ぶサーバーがありません。 |
| ノーコードビルダー（Wix、Squarespace、Carrd） | サーバー側の検証コードを追加できません。 |
| 個人開発者または小さなチーム | 問い合わせやサインアップのフォームのために、バックエンドを立ち上げて運用する価値がありません。 |
| すでにバックエンドを動かしているが、このフォームのためではない | 1 つのフォームをフォワーダーに向け、スタックの残りをそのままにできます。 |
バックエンドを動かしていてそこで検証したいなら、代わりに バックエンドで検証する を使ってください。2 つは層ではなく、選択肢です。
どう動くか
フォワーダーは、配信にかかる一瞬の間だけ、送信をメモリにのみ保持します。ポストと配信の間にストレージはなく、caputchin-token フィールドはペイロードがあなたの宛先に届く前に取り除かれます。
宛先
サイトキーごとに、片方または両方を設定します。両方を有効にするのはよくあるパターンです。処理のために webhook へ送り、自分にコピーをメールします。
| 宛先 | 受け取るもの |
|---|---|
| Webhook | あなたのフォームのフィールドに、Caputchin の検証メタデータを足して運ぶ JSON の POST。 |
| メール | フォームのフィールドと、Caputchin が送信を検証したと記すフッターを伴う素のメール。 |
配信は署名されません。webhook 呼び出しを認証するのはフォワーダー URL の秘匿性なので、URL を公開リポジトリやクライアント側のコードの外に保ってください。設定チュートリアル が正確な webhook ペイロードを示します。
何が秘匿されるか
ホスト型認証は、Caputchin のほかの部分と同じ、訪問者データなしの姿勢に従います：
- 送信は決して保存されません。 それらは転送の間プロセスメモリに住み、それから消えます。記録が欲しければ、webhook 側で自分のものを作ってください。
- 送信者についてのデータは集めません。 IP なし、User-Agent なし、フィンガープリントなし、追跡なし。
- テレメトリは集計のみ。 Caputchin は、宛先が健全かを見られるよう、配信の成功と失敗を数えますが、決してどの送信の中身も数えません。統計 を参照してください。
顧客が提供する URL がどう安全に保たれるか
Caputchin のサーバーが呼ぶ URL は、典型的な Server-Side Request Forgery のリスクです。フォワーダーは、ホストがプライベート、ループバック、リンクローカル、またはクラウドメタデータのアドレスであるどの webhook URL も拒否します。保存するときと、配信のたびに直前にもう一度です。ブロックされるカテゴリには次が含まれます：
| カテゴリ | 例 |
|---|---|
| ループバックと未指定 | 127.0.0.1、0.0.0.0、::1 |
| プライベート（RFC 1918） | 10.x.x.x、172.16.x.x から 172.31.x.x、192.168.x.x |
| リンクローカルとクラウドメタデータ | 169.254.x.x、特にメタデータエンドポイント 169.254.169.254 |
| キャリアグレード NAT | 100.64.x.x から 100.127.x.x |
| マルチキャストと予約済み | 224.x.x.x 以上 |
| 内部ホスト名 | localhost、そして .local、.localhost、.internal で終わるどのホストも |
| プライベート IPv6 | リンクローカル（fe80::/10）とユニークローカル（fc00::/7）のアドレス |
ブロックされるアドレスを偽装しようとするエンコーディングも捕まえます。http://2130706433/ のような十進整数のホストや、http://0x7f000001/ のような十六進のホスト（どちらも 127.0.0.1 を意味します）は拒否されます。受け付けるのは http と https の URL だけで、ほかのスキームは拒みます。フォワーダーはリダイレクトの追従も拒むので、webhook エンドポイントが呼び出しを内部のターゲットへ跳ね返すことはできません。ブロックされた URL は、特定のものではなく一般的なエラーとして現れるので、ネットワークを探るのに使えません。したがって、あなたの webhook は公開の https URL に置かなければなりません。
意図的に省かれているもの
- 送信の受信箱なし。 ダッシュボードで閲覧する、保存された送信の履歴はありません。
- ファーストパーティの Discord、Slack、Telegram、SMS アダプターなし。 webhook とメールだけ。webhook はあなたの側でそれらのどれにも展開できます。
- ファイルアップロードなし。 フォワーダーはテキストフィールドを受け付けます。ファイルを運ぶ送信は拒否されます。
- ペイロード変換なし。 フォームがポストするものが、検証メタデータを足して、あなたの宛先が受け取るものです。
あわせて読む
- ホスト型認証を設定する：まずテスト受信箱に配線する手順。
- ホスト型認証の統計：配信の健全性を読む。
- バックエンドで検証する：サーバーを動かす場合の選択肢。