Kasada-Header mit cURL generieren

Das Skript benötigt Bash, cURL 7.76 oder neuer, jq und openssl. Setzen Sie SOLVETHREE_API_KEY auf Ihren Workspace-API-Schlüssel und SOLVETHREE_PROXY auf die URL Ihres HTTP- oder HTTPS-Proxys. Belassen Sie den API-Schlüssel auf der Serverseite und lassen Sie Shell-Tracing deaktiviert.

Dieses Beispiel verwendet durchgehend einen Proxy. Eine Kasada-Anfrage benötigt type, url und genau eines der Felder proxy oder proxyCandidates; sie darf keine reCAPTCHA-Felder wie site oder action, keine session und keine benutzerdefinierten Felder zur Browseridentität enthalten. Siehe die Kasada-Anfragespezifikation.

#!/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.

Ersetzen Sie die Beispiel-Ziel-URL sowohl im Aufgabenbody als auch im abschließenden cURL-Aufruf durch die vorgesehene URL des unterstützten Workflows. Lassen Sie nicht für eine URL lösen, um das Ergebnis dann an ein unbeteiligtes Ziel zu senden.

Das Skript authentifiziert sich mit einem Bearer-Header, erstellt eine Aufgabe und fragt nur deren zurückgegebene ID ab. Für die Erstellung gilt ein Anfrage-Timeout von 30 Sekunden; die Statusabfrage verwendet eine lokale Frist von 180 Sekunden und zeitlich begrenzte GET-Anfragen. Dies sind Skriptgrenzen, keine Garantien für die Lösungsdauer. Weder automatische Wiederholungen noch das Folgen von Weiterleitungen sind aktiviert.

pending und solving bedeuten, dass die Statusabfrage fortgesetzt werden soll. Nur ready enthält eine verwendbare Lösung. Das Skript liest das unverarbeitete Objekt solution.headers mit jq und wandelt jeden Eintrag in eine Zeile einer Header-Datei um; es wählt weder einen einzelnen Header aus noch behandelt es die Aufgaben-ID als Lösung.

Die abschließende Anfrage lädt diese Header-Datei, setzt solution.userAgent und solution.secChUa und verwendet den ursprünglichen Proxy. Verwenden Sie diese Werte gemeinsam, statt sie durch Ihre üblichen Browserheader zu ersetzen.

API-Antworten, generierte Header und die Zielantwort verbleiben in einem privaten temporären Verzeichnis, statt ausgegeben zu werden. Halten Sie sie aus regulären Protokollen heraus und aktivieren Sie kein Shell-Tracing.

Speichern Sie die ausgegebenen Wiederherstellungs-IDs. Ein erneuter Skriptlauf generiert eine neue requestId; er ist kein Wiederherstellungsversuch. Um die Erstellung wiederaufzunehmen, verwenden Sie die gespeicherte Anfrage-ID mit exakt den ursprünglichen Aufgabeneingaben erneut. Das Skript löscht seine Eingabedatei beim Beenden. Bewahren Sie diese Eingaben daher sicher auf, wenn Sie die Anfrage rekonstruieren müssen.

Beim POST tritt eine Zeitüberschreitung auf, bevor eine Aufgaben-ID zurückgegeben wird.

Ein Verbindungs-Timeout beweist nicht, dass die Aufgabenerstellung fehlgeschlagen ist.

Probiere Folgendes: Senden Sie dieselbe Aufgabenanfrage mit der gespeicherten requestId. Identische Eingaben stellen die bestehende Aufgabe wieder her; geänderte Eingaben bei Wiederverwendung dieser ID führen zu einem Konflikt.

Die lokale Frist für die Statusabfrage läuft ab.

Prüfen Sie anhand der ausgegebenen Aufgaben-ID, ob die bestehende Aufgabe noch den Status pending oder solving hat.

Probiere Folgendes: Setzen Sie die GET-Statusabfrage für diese ID mit einer weiteren endlichen Frist fort. Erstellen Sie nicht allein deshalb eine Ersatzaufgabe, weil die lokale Wartezeit abgelaufen ist.

Eine API-Anfrage gibt eine HTTP-Antwort ohne Erfolgsstatus zurück.

Die API-Aufrufe verwenden --fail-with-body, sodass cURL beendet wird, bevor das Skript Erfolgsnutzdaten liest.

Probiere Folgendes: Fügen Sie zur Diagnose einen HTTP-Fehler-Handler hinzu, der den gespeicherten Antwortbody vor dem Bereinigen vertraulich prüft. Beheben Sie das gemeldete Anfrageproblem, statt es blind mit unveränderten Eingaben erneut zu versuchen.

Die Aufgabe erreicht den Status failed.

Das Beispiel gibt eine allgemeine Fehlermeldung aus; die Antwort enthält außerdem errorCode und error.

Probiere Folgendes: Prüfen Sie diese Felder im Fehlerzweig vor dem Bereinigen und beenden Sie dann die Statusabfrage für diese Aufgabe. Entscheiden Sie anhand der gemeldeten Ursache, was geändert werden muss. Fehlgeschlagene Lösungen werden erstattet.