cURL で Kasada ヘッダーを生成する
KasadaTask を作成して ready を待ち、返されたブラウザー識別情報とともに、solution.headers オブジェクト全体を同じプロキシ経由で送信します。スタンドアロンの Kasada は現在、www.ticketmaster.com の HTTPS ターゲットに対応しています。
このページの内容
cURL で作成、ポーリング、送信する
このスクリプトには、Bash、cURL 7.76 以降、jq、openssl が必要です。SOLVETHREE_API_KEY にワークスペースの API キーを、SOLVETHREE_PROXY に HTTP または HTTPS プロキシの URL を設定してください。API キーはサーバー側に保持し、シェルトレースは無効にしてください。
この例では、全体を通して 1 つのプロキシを使用します。Kasada リクエストには type、url、および proxy または proxyCandidates のいずれか一方だけが必要です。site や action などの reCAPTCHA フィールド、session、カスタムのブラウザー識別情報フィールドを含めてはいけません。Kasada リクエスト仕様を参照してください。
#!/usr/bin/env bash
set -euo pipefail
: "${SOLVETHREE_API_KEY:?Set the API key}" "${SOLVETHREE_PROXY:?Set the proxy}"
# Requires bash, curl, jq and openssl. Do not enable shell tracing.
work=$(mktemp -d)
chmod 700 "$work"
trap 'rm -rf "$work"' EXIT
request_id=$(openssl rand -hex 16)
printf 'Recovery requestId=%s\n' "$request_id"
printf 'Authorization: Bearer %s\n' "$SOLVETHREE_API_KEY" > "$work/auth"
jq -n --arg proxy "$SOLVETHREE_PROXY" --arg id "$request_id" '{"type":"KasadaTask","url":"https://www.ticketmaster.com/","proxy":$proxy,"requestId":$id}' > "$work/input.json"
api='https://api.solvethree.com/v1'
curl --fail-with-body --silent --show-error --max-time 30 \
--header @"$work/auth" --header 'Content-Type: application/json' \
--data-binary @"$work/input.json" --output "$work/result.json" "$api/tasks?waitMs=0"
task_id=$(jq -er '.id' "$work/result.json")
encoded_id=$(jq -nr --arg id "$task_id" '$id|@uri')
printf 'Recovery taskId=%s\n' "$task_id"
deadline=$((SECONDS + 180))
while [[ $(jq -r '.status' "$work/result.json") =~ ^(pending|solving)$ ]]; do
remaining=$((deadline - SECONDS))
(( remaining > 0 )) || { echo 'Local deadline reached; resume the saved task ID' >&2; exit 1; }
timeout=$((remaining < 25 ? remaining : 25))
curl --fail-with-body --silent --show-error --max-time "$timeout" \
--header @"$work/auth" --output "$work/result.json" "$api/tasks/$encoded_id?waitMs=15000"
[[ $(jq -r '.status' "$work/result.json") =~ ^(pending|solving)$ ]] && sleep 1 || true
done
[[ $(jq -r '.status' "$work/result.json") == ready ]] || { echo 'Solver task failed' >&2; exit 1; }
user_agent=$(jq -er '.solution.userAgent' "$work/result.json")
client_hints=$(jq -er '.solution.secChUa' "$work/result.json")
jq -r '.solution.headers | to_entries[] | "\(.key): \(.value)"' "$work/result.json" > "$work/target-headers"
curl --silent --show-error --max-time 30 --proxy "$SOLVETHREE_PROXY" \
--header @"$work/target-headers" --user-agent "$user_agent" \
--header "sec-ch-ua: $client_hints" --output "$work/target-response" \
--write-out 'Target HTTP %{http_code}\n' 'https://www.ticketmaster.com/'
# Inspect the application's response before treating the operation as successful.
# Replace the example target path with the actual supported workflow URL.タスクボディと最後の cURL 呼び出しの両方で、例のターゲット URL を、対象のサポートされているワークフローの URL に置き換えてください。ある URL 向けに解決した結果を、無関係なターゲットへ送信しないでください。
このスクリプトは Bearer ヘッダーで認証し、1 つのタスクを作成して、返された ID のみをポーリングします。作成リクエストのタイムアウトは 30 秒です。ポーリングには 180 秒のローカル期限と、時間制限付きの GET リクエストを使用します。これらはスクリプトの制限であり、解決時間を保証するものではありません。自動再試行とリダイレクトの追跡は、どちらも有効になっていません。
ヘッダーオブジェクト全体を適用する
pending と solving は、ポーリングの継続を意味します。使用可能な解決結果が含まれるのは ready の場合だけです。このスクリプトは jq で生の solution.headers オブジェクトを読み取り、すべてのエントリをヘッダーファイルの各行に変換します。単一のヘッダーだけを選んだり、タスク ID を解決結果として扱ったりはしません。
最後のリクエストは、そのヘッダーファイルを読み込み、solution.userAgent と solution.secChUa を設定して、元のプロキシを使用します。普段使用しているブラウザーヘッダーに置き換えず、これらの値を一緒に使用してください。
API レスポンス、生成されたヘッダー、ターゲットのレスポンスは出力せず、非公開の一時ディレクトリに保持します。通常のログに含めず、シェルトレースを有効にしないでください。
別のタスクを作成せず、既存のタスクを復旧する
出力された復旧用 ID を保存してください。スクリプトを再実行すると新しい requestId が生成されるため、復旧の試みにはなりません。作成処理を復旧するには、保存したリクエスト ID を、元とまったく同じタスク入力とともに再利用してください。スクリプトは終了時に入力ファイルを削除するため、リクエストを再構築する必要がある場合は、その入力を安全に保管してください。
- タスク ID が返される前に POST がタイムアウトする。
接続タイムアウトは、タスクの作成が失敗した証拠にはなりません。
試してみましょう： 保存した requestId を使って、同じタスクリクエストを送信してください。入力が同一なら既存のタスクを復旧できます。同じ ID を再利用しながら入力を変更すると競合します。
- ローカルのポーリング期限が切れる。
出力されたタスク ID を使って、既存のタスクがまだ待機中または解決中かを確認してください。
試してみましょう： 新たに有限の期限を設定し、その ID の GET ポーリングを再開してください。ローカルでの待機が終了したというだけで、代わりのタスクを作成しないでください。
- API リクエストが成功以外の HTTP レスポンスを返す。
API 呼び出しは --fail-with-body を使用するため、スクリプトが成功時のペイロードを読み取る前に cURL が終了します。
試してみましょう： 診断のため、クリーンアップ前に保存済みレスポンスボディを非公開で確認する HTTP エラーハンドラーを追加してください。同じ入力をやみくもに再試行するのではなく、報告されたリクエストの問題を修正してください。
- タスクが failed になる。
この例は汎用的な失敗メッセージを出力します。レスポンスには errorCode と error も含まれています。
試してみましょう： クリーンアップ前に失敗分岐でこれらのフィールドを確認し、そのタスクのポーリングを停止してください。報告された原因に基づいて、変更すべき点を判断してください。失敗した解決処理の料金は返金されます。
参照元とAPIリファレンス
最初のタスクを実行しましょう。
$5のワークスペースクレジットで始められます。