Ein TMPT-Cookie mit cURL anfordern und verwenden

• Setzen Sie für Event das Feld url auf die genaue Event-URL.
• Setzen Sie für Login das Feld url auf die URL des Anmeldeeinstiegs.
• Geben Sie für dieses Skript einen einzelnen Proxy an. Es verwendet diesen Proxy erneut, wenn es das Cookie an das Ziel sendet.
• Nehmen Sie site, recaptchaType oder session nicht in die TMPT-Aufgabe auf.

Das Beispiel verwendet Login und eine Platzhalter-URL für die Ticketmaster-Startseite. Ersetzen Sie die Aufgaben-URL und das abschließende cURL-Ziel durch die tatsächlichen URLs für Ihren unterstützten Workflow. Wenn Sie ein Event-Cookie anfordern, ändern Sie auch die Aktion auf Event.

Führen Sie das Skript serverseitig mit Bash, cURL 7.76 oder neuer, jq und openssl aus. Setzen Sie SOLVETHREE_API_KEY auf Ihren Workspace-API-Schlüssel und SOLVETHREE_PROXY auf Ihre Proxy-URL. Lassen Sie Shell-Tracing deaktiviert: Es kann den Schlüssel, die Proxy-Zugangsdaten und das Cookie offenlegen.

#!/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":"TicketmasterTmptTask","url":"https://www.ticketmaster.com/","action":"Login","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")
cookie=$(jq -er '.solution.token' "$work/result.json")
curl --silent --show-error --max-time 30 --proxy "$SOLVETHREE_PROXY" \
  --cookie "tmpt=$cookie" --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.

Das Skript authentifiziert sich mit einem Bearer-Schlüssel, erstellt mit POST /v1/tasks eine Aufgabe und fragt anschließend nur deren zurückgegebene ID mit GET /v1/tasks/:id ab. Sowohl pending als auch solving bedeuten, dass die Statusabfrage fortgesetzt werden soll; nur ready liefert eine verwendbare Lösung.

Für die Erstellung gilt ein Anfrage-Timeout von 30 Sekunden. Die Abfrageschleife prüft vor jeder Statusabfrage eine lokale Frist von 180 Sekunden und begrenzt einzelne Statusanfragen auf höchstens 25 Sekunden. Bei Erreichen dieser Frist stoppt das Skript; das belegt nicht, dass die entfernte Aufgabe fehlgeschlagen ist.

Für die Zielanfrage erstellt die cURL-Option --cookie den Cookie-Header aus dem reinen Token. Das Skript wendet außerdem solution.userAgent, solution.secChUa und den ursprünglichen Proxy an. Es aktiviert weder automatische Wiederholungen noch das Folgen von Weiterleitungen.

Bei der Aufgabenerstellung tritt eine Zeitüberschreitung auf, bevor eine Aufgaben-ID ausgegeben wird.

Ein Verbindungs-Timeout beweist nicht, dass die API die Aufgabe nicht erstellen konnte.

Probiere Folgendes: Bewahren Sie die ausgegebene requestId und die ursprünglichen Aufgabeneingaben auf. Senden Sie dieselben Eingaben mit dieser requestId erneut, um die bestehende Aufgabe wiederherzustellen, statt eine neue logische Aufgabe zu erstellen. Geänderte Eingaben bei Wiederverwendung der ID führen zu einem Konflikt.

Ein API-Aufruf gibt eine HTTP-Antwort ohne Erfolgsstatus zurück.

Dies ist ein Fehler auf HTTP-Ebene, kein Aufgabenstatus. Die Skriptoption --fail-with-body lässt den Aufruf fehlschlagen und speichert dabei den Antwortbody.

Probiere Folgendes: Prüfen Sie die gespeicherte API-Antwort, bevor die temporären Dateien bereinigt werden. Beheben Sie das gemeldete Problem, statt die Antwort als erfolgreiche Aufgabe zu parsen oder dieselben Eingaben blind zu wiederholen.

Das Skript meldet, dass die Solver-Aufgabe fehlgeschlagen ist.

Das Skript gibt eine allgemeine Fehlermeldung aus; die fehlgeschlagene Aufgabe enthält errorCode und error.

Probiere Folgendes: Rufen Sie die Aufgabe anhand der ausgegebenen Aufgaben-ID ab und prüfen Sie diese Felder. Beenden Sie die Statusabfrage für eine fehlgeschlagene Aufgabe. Fehlgeschlagene Lösungen werden erstattet.

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

Die Aufgabe kann weiterhin den Status pending oder solving haben.

Probiere Folgendes: Setzen Sie den Abruf mit der ausgegebenen Aufgaben-ID fort. Erstellen Sie nicht allein deshalb eine weitere Aufgabe, weil das lokale Skript nicht mehr wartet.

Die Aufgabe ist bereit, aber das Ziel lehnt die Anfrage ab.

Prüfen Sie das ausgehende Cookie, den User-Agent, die Client Hints, den Proxy und die Ziel-URL – nicht nur den Solver-Status.

Probiere Folgendes: Bestätigen Sie, dass das tmpt-Cookie solution.token enthält, ohne Set-Cookie-Präfix oder Attribute. Verwenden Sie die zurückgegebene Identität und den ursprünglichen Proxy und prüfen Sie, ob die Ziel-URL zum vorgesehenen Workflow passt.