HTTPieでCAPTCHA APIをテストする
HTTPieでタスクを1つ作成し、そのIDを保存してから、同じタスクを取得します。接続がタイムアウトしても論理的に別のタスクを作成せずに済むように、POSTの前にrequestIdを記録してください。
このページの内容
リクエストを準備する
- HTTPieとjqをインストールし、Bashで例を実行してください。これらのコマンドはHTTPieの
http実行ファイルを使用します。curlや、curlを呼び出すシェルエイリアスではありません。 - 環境変数
SOLVETHREE_API_KEYにワークスペースのAPIキーを設定してください。信頼できるマシンで実行し、キーをブラウザーのコードに含めないでください。 - コンソールで、対象のホスト名に対応する有効なプロファイルを設定してください。ホスト名とアクションを送信しても、プロファイルは作成されません。サイトプロファイルの設定を参照してください。
- 例のホスト名、アクション、プロキシURLを置き換えてください。パス、クエリ、フラグメントを含まないHTTPまたはHTTPSプロキシURLを使用します。
- requestIdのプレースホルダーを、この論理タスクに固有のIDに置き換えてください。使用できるのは1–64文字のASCII英字、数字、アンダースコア、ハイフンです。リクエストを送信する前に保存してください。
このリクエストはreCAPTCHA Enterprise用です。recaptchaType のデフォルト値は enterprise-v3 です。site、action、および proxy または proxyCandidates のどちらか一方だけが必要です。この例ではプロキシを1つ使用します。type フィールドや url フィールドは追加しないでください。
タスクを作成してIDを保存する
set -eu
umask 077
# Install HTTPie and jq. Keep the same request.json for recovery.
cat > request.json <<'JSON'
{
"site": "accounts.example.com",
"action": "login",
"proxy": "http://USER:PASSWORD@PROXY:PORT",
"requestId": "replace-with-one-unique-logical-task-id"
}
JSON
# This file contains proxy credentials; keep it private.
http --check-status --timeout=30 POST https://api.solvethree.com/v1/tasks \
Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==0 < request.json > task.json
TASK_ID=$(jq -r '.id' task.json)
http --check-status --timeout=30 GET "https://api.solvethree.com/v1/tasks/$TASK_ID" \
Authorization:"Bearer $SOLVETHREE_API_KEY" waitMs==15000
# pending/solving: retrieve the same ID again, within a finite deadline.
# ready: use solution. failed: stop and inspect errorCode/error.
# A timed-out POST is recovered with the unchanged file and requestId.引用符で囲まれたJSON文字列は request.json に書き込まれ、HTTPieが標準入力から読み取ります。AuthorizationヘッダーはBearer認証でキーを送信します。request.json にはプロキシの認証情報が含まれるため、非公開で管理してください。
waitMs==0 と waitMs==15000 はHTTPieのクエリパラメーターであり、JSON本文のフィールドではありません。POSTは待機なしを指定し、GETは15,000ミリ秒の待機を指定します。HTTPieの別のオプション --timeout=30 は、クライアントのタイムアウトを30秒に設定します。
POSTのレスポンスは task.json に保存され、jqがGETに使用する id を抽出します。コマンドは順番に実行してください。HTTPieが失敗を報告すると、set -eu によってスクリプトが停止し、不完全なレスポンスが取得処理に使用されるのを防ぎます。
HTTPの成功はタスクの準備完了ではない
--check-status は成功以外のHTTPレスポンスを検出します。本文を成功したタスクのレスポンスとして扱う前に、それらに対処してください。HTTPリクエストが成功しても、未完了または失敗したタスクが返されることがあります。次にJSONの status を確認してください。
| ステータス | 次の操作 |
|---|---|
| pendingまたはsolving | 自分で設定した有限の制限時間内で、同じタスクIDを再度取得してください。このタスクがまだ準備できていないという理由だけで、別のタスクを作成しないでください。 |
| ready | 返されたソリューションを使用してください。使用可能なソリューションがあるのは、このステータスだけです。 |
| failed | ポーリングを停止し、errorCodeとerrorを確認してください。解決に失敗した場合は返金されます。無効な入力を変更せずに、むやみに再試行しないでください。 |
この例では取得を1回行い、ポーリングループは実行しません。準備が完了したソリューションを本来の対象に送信する際は、返された userAgent と secChUa を、成功したプロキシとともに使用してください。準備完了はsolvethreeがソリューションを生成したことを意味し、アプリケーションのリクエストが成功したことを意味するわけではありません。
タイムアウトしたPOSTを復旧する
クライアントがタイムアウトしても、タスク作成が失敗したとは限りません。すでにタスクIDがある場合は、そのタスクを取得してください。IDを受け取る前にPOSTがタイムアウトした場合は、元のrequestIdを含む request.json を変更せずにPOSTを再実行してください。同じIDとタスク入力を使用すると、既存のタスクが返されます。
空または不完全な task.json からIDを抽出しないでください。まずPOSTを復旧してください。同じrequestIdを再利用する間は、プロキシ、アクション、その他のタスク入力を変更しないでください。入力が異なると競合します。新しいrequestIdは、論理的に新しいタスクを作成する場合にのみ使用してください。
最初のタスクを実行しましょう。
$5のワークスペースクレジットで始められます。