reCAPTCHA解決APIとsiteverifyの違い
いいえ。Googleのsiteverifyエンドポイントは、reCAPTCHAレスポンストークンを発行できません。クライアントから渡されたトークンを検証します。Enterpriseの評価も既存のトークンを評価するもので、どちらのエンドポイントもサイトキーからトークンを生成することはありません。
このページの内容
必要な処理に合うAPIを選ぶ
| API | 指定するもの | 取得できる結果 |
|---|---|---|
| Google siteverify | 既存のレスポンストークン | 検証結果 |
| Google Enterpriseの評価 | 既存のレスポンストークン | そのトークンの評価 |
| solvethreeタスク | 対応サイトのホスト名、アクション、プロキシ設定 | readyの結果に解決トークンを含むタスク |
Google の reCAPTCHA v3 フローでは、クライアント SDK がレスポンストークンを生成し、サイト所有者のバックエンドが siteverify で検証します。Enterprise フローでは、クライアント SDK がトークンを生成し、バックエンドが評価を作成します。
所有するサイトに検証を追加する場合は、適切な Google のフローを使用してください。対応する対象向けの解決サービスが必要な場合は、solvethree のタスク API を使用してください。ソルバーは対象が評価するためのトークンを提供するものであり、対象側の検証を置き換えるものではありません。
実際のソルバーリクエストの例
まず、対象サイトの有効なプロファイルがワークスペースで利用可能であることを確認してください。ホスト名とアクションを送信しても、プロファイルは作成されません。この前提条件を満たしていない場合は、サイトプロファイルの設定を参照してください。
solvethree API の POST /v1/tasks でタスクを作成します。Authorization: Bearer の後にワークスペースの API キーを指定してください。このキーはサーバー上で保持してください。
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://user:[email protected]:8080",
"requestId": "example_login_001"
}例のホスト名、アクション、プロキシを、対象リクエストの値に置き換えてください。site は完全な URL ではなくホスト名です。reCAPTCHA リクエストには proxy または proxyCandidates のいずれか一方だけが必要です。type や url は追加しないでください。この例では、デフォルトの recaptchaType である enterprise-v3 を使用しています。ゲートウェイは v3 も受け付けます。
GET /v1/tasks/:id でタスクを取得します。ステータスが pending または solving の間はポーリングを続けてください。使用可能な解決結果が含まれるのは ready の場合だけです。failed になったら、ポーリングを停止し、errorCode と error を確認してください。
テスト評価で Enterprise トークンを消費しない
Google のドキュメントによると、Enterprise のウェブサイト用レスポンストークンは 2 分で有効期限が切れ、評価できるのは 1 回だけです。保護されたリクエストを送信する直前に解決を依頼してください。トークンが機能するか確認するためだけに評価を作成すると、本来の対象が使用する前にトークンを消費してしまう可能性があります。
対象には、タスク ID ではなく solution.token を送信してください。返された userAgent と secChUa のブラウザー識別情報を、解決時に成功したプロキシとともに使用してください。プロキシを切り替えたり、無関係なブラウザーヘッダーを混在させたりすると、後続のリクエストが失敗する可能性があります。
タスクの ready は、解決結果が利用可能であることを意味します。対象がアプリケーションリクエストを受け入れたことを意味するものではありません。受け入れられたかどうかは、タスクの作成や準備完了ではなく、対象のレスポンスから判断してください。
参照元とAPIリファレンス
最初のタスクを実行しましょう。
$5のワークスペースクレジットで始められます。