Générer des en-têtes Kasada avec cURL

Par solvethree4 min de lecture

Créez une tâche KasadaTask, attendez l’état ready, puis envoyez l’objet solution.headers complet avec l’identité de navigateur renvoyée via le même proxy. Kasada en mode autonome prend actuellement en charge les cibles HTTPS sur www.ticketmaster.com.

Sur cette page

Créer, interroger et envoyer avec cURL

Le script nécessite 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 HTTP ou HTTPS. Conservez la clé API côté serveur et laissez le traçage du shell désactivé.

Cet exemple utilise un seul proxy du début à la fin. Une requête Kasada nécessite type, url et exactement l’un des deux champs proxy ou proxyCandidates ; elle ne doit pas inclure de champs reCAPTCHA tels que site ou action, de session, ni de champs d’identité de navigateur personnalisés. Consultez le contrat de requête Kasada.

KASADA · créer, interroger périodiquement et appliquer le résultat
#!/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.

Remplacez l’URL cible de l’exemple, à la fois dans le corps de la tâche et dans l’appel cURL final, par l’URL prévue pour le flux pris en charge. N’effectuez pas de résolution pour une URL pour ensuite envoyer le résultat à une cible sans rapport.

Le script s’authentifie avec un en-tête Bearer, crée une seule tâche et interroge uniquement l’identifiant qu’elle renvoie. La requête de création a un délai d’expiration de 30 secondes ; l’interrogation utilise une échéance locale de 180 secondes et des requêtes GET limitées dans le temps. Il s’agit de limites du script, pas de garanties sur la durée de résolution. Aucune nouvelle tentative automatique ni aucun suivi des redirections ne sont activés.

Appliquer l’objet d’en-têtes complet

pending et solving indiquent qu’il faut poursuivre l’interrogation. Seul l’état ready contient une solution utilisable. Le script lit l’objet brut solution.headers avec jq et convertit chaque entrée en une ligne du fichier d’en-têtes ; il ne sélectionne pas un seul en-tête et ne traite pas l’identifiant de tâche comme la solution.

La requête finale charge ce fichier d’en-têtes, définit solution.userAgent et solution.secChUa, et utilise le proxy d’origine. Conservez ces valeurs ensemble plutôt que de les remplacer par vos en-têtes de navigateur habituels.

Les réponses de l’API, les en-têtes générés et la réponse de la cible restent dans un répertoire temporaire privé au lieu d’être affichés. Ne les incluez pas dans les journaux courants et n’activez pas le traçage du shell.

Récupérer la tâche plutôt que d’en créer une autre

Conservez les identifiants de récupération affichés. Relancer le script génère un nouveau requestId ; ce n’est pas une tentative de récupération. Pour récupérer la création, réutilisez l’identifiant de requête enregistré avec exactement les données d’entrée de la tâche d’origine. Le script supprime son fichier d’entrée à la sortie ; conservez donc ces données de manière sécurisée si vous devez reconstituer la requête.

La requête POST expire avant qu’un identifiant de tâche ne soit renvoyé.

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

Essayez ceci : Envoyez la même demande de tâche avec le requestId enregistré. Des données d’entrée identiques permettent de récupérer la tâche existante ; modifier les données tout en réutilisant cet identifiant provoque un conflit.

Le délai local d’interrogation expire.

Utilisez l’identifiant de tâche affiché pour vérifier si la tâche existante est toujours en attente ou en cours de résolution.

Essayez ceci : Reprenez les interrogations GET pour cet identifiant avec une nouvelle échéance finie. Ne créez pas de tâche de remplacement simplement parce que l’attente locale est terminée.

Une requête API renvoie une réponse HTTP qui n’indique pas un succès.

Les appels API utilisent --fail-with-body ; cURL se termine donc avant que le script ne lise une réponse de succès.

Essayez ceci : Pour le diagnostic, ajoutez un gestionnaire d’erreurs HTTP qui examine en privé le corps de réponse enregistré avant le nettoyage. Corrigez le problème de requête signalé plutôt que de réessayer aveuglément avec des données inchangées.

La tâche passe à l’état failed.

L’exemple affiche un message d’échec générique ; la réponse contient également errorCode et error.

Essayez ceci : Inspectez ces champs dans la branche d’échec avant le nettoyage, puis cessez d’interroger cette tâche. Appuyez-vous sur la cause signalée pour décider quoi modifier. Les résolutions échouées sont remboursées.

Lancez votre première tâche.

Démarrez avec $5 de crédit dans votre espace de travail.

Créer un espace de travail
Générer des en-têtes Kasada avec cURL · solvethree