Demander et utiliser un cookie TMPT avec cURL

• Pour Event, définissez url sur l’URL exacte de l’événement.
• Pour Login, définissez url sur l’URL d’entrée du parcours de connexion.
• Fournissez un seul proxy pour ce script. Il réutilise ce proxy pour envoyer le cookie à la cible.
• N’incluez pas site, recaptchaType ou session dans la tâche TMPT.

L’exemple utilise Login et une URL de page d’accueil Ticketmaster à titre indicatif. Remplacez l’URL de la tâche et la cible cURL finale par les URL réelles de votre flux pris en charge. Si vous demandez un cookie d’événement, remplacez également l’action par Event.

Exécutez le script côté serveur avec Bash, cURL 7.76 ou version ultérieure, jq et openssl. Définissez SOLVETHREE_API_KEY sur la clé API de votre espace de travail et SOLVETHREE_PROXY sur l’URL de votre proxy. Laissez le traçage du shell désactivé : il peut exposer la clé, les identifiants du proxy et le cookie.

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

Le script s’authentifie avec une clé Bearer, crée une seule tâche avec POST /v1/tasks, puis interroge uniquement l’identifiant renvoyé avec GET /v1/tasks/:id. Les états pending et solving indiquent tous deux qu’il faut poursuivre l’interrogation ; seul l’état ready fournit une solution utilisable.

La requête de création a un délai d’expiration de 30 secondes. La boucle d’interrogation vérifie une échéance locale de 180 secondes avant chaque interrogation et limite chaque requête d’interrogation à 25 secondes au maximum. Atteindre cette échéance arrête ce script ; cela ne permet pas d’établir que la tâche distante a échoué.

Pour la requête vers la cible, l’option --cookie de cURL construit l’en-tête Cookie à partir du jeton brut. Le script applique également solution.userAgent, solution.secChUa et le proxy d’origine. Il n’active ni les nouvelles tentatives automatiques ni le suivi des redirections.

La création de la tâche expire avant qu’un identifiant de tâche ne soit affiché.

L’expiration du délai de connexion ne prouve pas que l’API n’a pas créé la tâche.

Essayez ceci : Conservez le requestId affiché et les données d’entrée de la tâche d’origine. Renvoyez ces mêmes données avec ce requestId pour récupérer la tâche existante plutôt que de créer une nouvelle tâche logique. Modifier les données tout en réutilisant l’identifiant provoque un conflit.

Un appel API renvoie une réponse HTTP qui n’indique pas un succès.

Il s’agit d’une erreur au niveau HTTP, pas d’un état de tâche. L’option --fail-with-body du script fait échouer l’appel tout en enregistrant le corps de la réponse.

Essayez ceci : Inspectez la réponse API enregistrée avant le nettoyage des fichiers temporaires. Corrigez le problème signalé plutôt que d’analyser la réponse comme si elle décrivait une tâche réussie ou de renvoyer aveuglément des données inchangées.

Le script signale l’échec de la tâche de résolution.

Le script affiche un message d’échec générique ; la tâche en échec contient errorCode et error.

Essayez ceci : Récupérez l’identifiant de tâche affiché et inspectez ces champs. Cessez d’interroger une tâche en échec. Les résolutions échouées sont remboursées.

Le délai local d’interrogation expire.

La tâche peut encore être en attente ou en cours de résolution.

Essayez ceci : Reprenez la récupération à l’aide de l’identifiant de tâche affiché. Ne créez pas une autre tâche simplement parce que le script local a cessé d’attendre.

La tâche est prête, mais la cible rejette la requête.

Inspectez le cookie sortant, l’agent utilisateur, les indications client, le proxy et l’URL cible, pas seulement l’état de la résolution.

Essayez ceci : Vérifiez que le cookie tmpt contient solution.token, sans préfixe Set-Cookie ni attributs. Utilisez l’identité renvoyée et le proxy d’origine, et vérifiez que l’URL cible correspond au flux prévu.