リバースプロキシでサイト全体にゲートをかける

Caputchin の通常の使い方は、ページに ウィジェット を埋め込み、トークンをバックエンドで検証することです。それにはウィジェットを置く場所と、トークンを確認するバックエンドが要ります。プロキシゲートはどちらも要りません。あなたの リバースプロキシ で、サイトやルート全体の手前に全画面の検証を置きます。訪問者はゲームを一つ解き、短命のパスを得て、パスが切れるまでサイトを歩き回ります。守られるアプリは一切触られません。

アプリ自体には何も足されないので、これはスクリプトを埋め込めないホストを守るやり方です。コンパイル済みのシングルページのログインポータル、アプライアンス、または認証プロキシの背後に座る社内ツールなどです。

誰のためのものか

インラインのウィジェットが合わないときにゲートへ手を伸ばします：

• アプリにウィジェットを置く場所がない。 封じられたログインポータル（Authelia など）、ベンダーのアプライアンス、または編集できないどの UI も。
• フォーム一つではなく、面全体にゲートをかけたい。 単一の送信での確認ではなく、「このサイトに達する前に、人間だと証明せよ」です。
• トークンを検証するバックエンドがない。 強制するのはプロキシで、書くべき /siteverify 呼び出しはありません。

あなたが管理する普通のページやフォームには、代わりに ウィジェット を埋め込んでください。そのほうが軽く、訪問者をリダイレクトしません。フォームはあるがバックエンドがないなら、ホスト型認証 のほうが合います。

どう動くか

一度の解答が多くのリクエストを買います。訪問者はゲームを一度遊び、その後はファーストパーティ Cookie が、切れるまでそのリクエストを通します。

プロキシはリクエストごとに、Caputchin へ小さな オーソライザー 呼び出しをします。リクエストが有効なパスを持たないとき、Caputchin は 401 を返し、プロキシは訪問者をホスト型チャレンジへリダイレクトします。パスが在って有効なとき、Caputchin は 204 を返し、プロキシはリクエストをあなたのアプリへ通します。

通過許可 Cookie

パスは cpt_gate という名のファーストパーティ Cookie に住み、それはあなたがホストする小さなコールバックが、あなた自身のドメインにセットします。署名付きで短命のトークンで、デバイスに紐づかないため、その安全性はまるごと Cookie の属性（HttpOnly、Secure、SameSite=Lax）と、あなたが選ぶ短い TTL から来ます。訪問者に Cookie をセットするので、Cookie ポリシーで開示してください。設定ガイド がコールバックと必要な属性を通しで説明します。

あえて省いているもの

• セルフホストのゲートなし。 Caputchin がチャレンジをホストしパスを検証します。あなたは検証器を動かしません。あなたのプロキシは Cookie を転送し、リダイレクトに従うだけです。
• リクエストごとのチェックで、ローカルなトークン検証ではない。 プロキシはリクエストごとに Caputchin へ尋ねます。あなたが選ぶ フェイルモード（オープンかクローズド）が、Caputchin が短時間到達できないときに何が起きるかを決めます。
• サイトキーごと、Cookie スコープの通過許可。 パスは一つのオリジンを通し、アカウント全体や複数ドメインは通しません。それは普通のファーストパーティ Cookie だからです。
• セッションでもログインでもない。 ゲートは人間がサイトに達したことを証明します。あなたのアプリは相変わらず認証と自分のレート制限を担います。二つは重なります。

あわせて読む

• プロキシゲートを設定する：有効にして、プロキシを端から端まで配線する。
• リバースプロキシのレシピ：nginx、Traefik、Caddy、そして Authelia の実例。
• プロキシゲートの統計：パススルー対チャレンジの比を読む。
• ホスト型認証：向ける先のフォームが実際にある場合の、バックエンドなしの選択肢。