reCAPTCHA v2 の仕組みと解決方法（近日公開）
reCAPTCHA v2 は Google の定番キャプチャです。「私はロボットではありません」というラベルのチェックボックスを表示し、訪問者について確信が持てない場合は画像チャレンジを追加します。そのソルバーは、サイトが Google で検証できる有効な応答トークンを作る必要があります。Scarnox の reCAPTCHA v2 サポートは近日公開予定です。このガイドでは、ウィジェットの仕組み、一般的に使われているアプローチ、そしてトークン型ソルバーに何を期待できるかを説明します。
Scarnox はまだ reCAPTCHA v2 をライブで解決していません。現在ライブのタスク種別は、プロキシなしの PopularCaptcha だけです。今すぐ reCAPTCHA v2 が必要なプロジェクトでは、以下のアプローチが現実的な選択肢です。
ウィジェットの仕組み
ページには data-sitekey 属性を持つコンテナ要素が埋め込まれています。その sitekey がサイトを Google に対して識別します。ウィジェットが読み込まれると、ブラウザ内でチェックを実行し、訪問者の振る舞い、クッキー、履歴を確認して、リスク評価を Google に送ります。
評価が低リスクであれば、チェックボックスが自動的にチェックされ、ウィジェットは g-recaptcha-response という隠しフィールドにトークンを書き込みます。評価が高リスクであれば、訪問者には画像チャレンジが表示されます。たとえば、特定の物体を含むタイルを選ぶものです。チャレンジに合格してもトークンが書き込まれます。
その後、サイトのバックエンドがそのトークンを、サイトのシークレットキーと一緒に Google の検証エンドポイントに送ります。Google は成功か失敗かを返します。検証はサーバー側で行われるため、Google での確認をせずにトークンを受け入れるフォームは、reCAPTCHA によって保護されていません。
なぜフラグが立つのか
チェックボックスはパズルではなく、リスクの判断です。主なきっかけは次のとおりです。
- 一つの IP アドレスからのリクエストの集中。
- クッキーも履歴もない新しいブラウザセッション。
- デフォルトのヘッドレス設定のような、自動化されたように見えるブラウザ環境。
- マウスの操作やタイピングとして人間らしくない入力のパターン。
ウィジェットそのものより、こうしたきっかけを理解することのほうが重要です。トラフィックがチェックボックスを引き起こさなければ、画像チャレンジを見ることもありません。
今日有効な一般的なアプローチ
これらのアプローチは広く使われており、正直なものです。正当な作業でチャレンジが表示される頻度を減らします。
- 実際のセッションを維持する。 ページごとに新規で始めるのではなく、クッキーと一貫したブラウザプロファイルをセッション中再利用します。
- リクエストのペースを守る。 一定の遅いペースは、バーストよりもずっと人間に近く見えます。
- ウィジェットには本物のブラウザを使う。 通常の設定のフルブラウザは、機能を削ぎ落としたヘッドレス設定よりフラグが立ちにくいです。よく使われる信号はヘッドレスブラウザ検出のガイドにまとめられています。
- 例外かテストキーを求める。 サイトを自分で管理している場合は、ステージングで Google の公開テストキーを使ってください。管理していない場合は、所有者に許可リストへの追加を依頼してください。
- 人間を介在させる。 低ボリュームの作業であれば、人間がチェックボックスを完了させ、トークンを渡すこともできます。遅いですが確実です。
これらのアプローチは、チャレンジが決して現れないことを保証するものではありません。頻度を減らすだけで、それが正当な作業を安定させます。
トークン型ソルバーが行うこと
reCAPTCHA v2 のトークン型ソルバーは、今日の PopularCaptcha と同じことをします。sitekey とページの URL を受け取り、有効な g-recaptcha-response トークンを作って、あなたのコードに返します。あなたのコードはそのトークンをフォームに入れ、期限が切れる前に送信します。
Scarnox は reCAPTCHA v2 のサポートが提供される時点で、タスク種別と追加フィールドを API リファレンスに記載します。それまでは、想定した仕様に対して開発しないでください。リクエストの形式は PopularCaptcha の例と似たものになると思われますが、正確な値はドキュメントで確認してください。
reCAPTCHA v2 の作業のチェックリスト
reCAPTCHA v2 のフォームに関わるジョブを計画する場合は、次の点を確認してください。
- サイトは自分のものか。そうであれば、ステージングではテストキーを使い、本番でのテストは最小限にしてください。
- 作業は正当か。公開データの収集や自分のワークフローは正当です。アカウントの悪用やスパムは正当ではありません。
- チェックボックスが静かなままでいられる程度に、リクエスト頻度は低いか。
- 画像チャレンジへの対応計画はあるか。人間が対応するか、ライブになった後はソルバーを使うか。
- トークンが存在するかだけでなく、サーバー側の検証結果を確認しているか。
よくある間違い
reCAPTCHA v2 の連携でよくある問題は、正しく見えるのにサイトが拒否するトークンです。その原因のほとんどは次の3つです。1つ目は sitekey とページの URL の不一致です。トークンはウィジェットが表示されたページに結びついているため、あるページから取得した sitekey を別のページに送ると失敗します。2つ目は古いトークンです。トークンは寿命が短いため、先に解決してから遅い一連の他の処理を行うスクリプトは、期限切れの値を送信してしまいます。3つ目は、自分の側でサーバー側の検証がないことです。テストでトークンが存在することだけを確認していると、検証のステップが失敗していることに気づけません。
2つ目のグループの間違いは、ウィジェットの周りのワークフローから生まれます。あるセッションでログインしてから、別のセッションでフォームを送信するのはよくある例です。検証がウィジェットを読み込んだセッションに依存することがあるためです。拒否されたフォームを何度も連続してリトライすると、セッションが不審に見えてしまい、一度のチャレンジが連続したチャレンジに発展することもあります。失敗したら、一度止まってページの状態を確認し、新しい値で一度だけ再試行してください。
責任を持ったスクレイピング
フォームがスクレイピングのジョブの一部であれば、開始前に robots.txt とサイトの利用規約を確認してください。リクエスト頻度を低く保ち、必要のない個人データは収集しないでください。ウェブスクレイピングは合法か？ で、主な検討事項を扱っています。