Genera cabeceras de Kasada con cURL

El script requiere Bash, cURL 7.76 o posterior, jq y openssl. Establece SOLVETHREE_API_KEY en la clave de API de tu espacio de trabajo y SOLVETHREE_PROXY en la URL de tu proxy HTTP o HTTPS. Mantén la clave de API en el servidor y el trazado del shell desactivado.

Este ejemplo utiliza un único proxy durante todo el proceso. Una solicitud de Kasada requiere type, url y exactamente uno de estos campos: proxy o proxyCandidates; no debe incluir campos de reCAPTCHA como site o action, ni session, ni campos de identidad de navegador personalizados. Consulta el contrato de solicitudes de 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.

Sustituye la URL de destino del ejemplo tanto en el cuerpo de la tarea como en la llamada final de cURL por la URL del flujo compatible que quieras utilizar. No resuelvas para una URL y envíes el resultado a un destino no relacionado.

El script se autentica con una cabecera Bearer, crea una tarea y consulta únicamente el ID devuelto. La creación tiene un tiempo de espera de 30 segundos por solicitud; las consultas utilizan un plazo local de 180 segundos y solicitudes GET con límites de tiempo. Estos son límites del script, no garantías sobre el tiempo de resolución. No se habilitan reintentos automáticos ni el seguimiento de redirecciones.

pending y solving indican que hay que seguir consultando. Solo ready contiene una solución utilizable. El script lee el objeto solution.headers sin procesar con jq y convierte cada entrada en una línea del archivo de cabeceras; no selecciona una sola cabecera ni trata el ID de la tarea como si fuera la solución.

La solicitud final carga ese archivo de cabeceras, establece solution.userAgent y solution.secChUa, y utiliza el proxy original. Mantén estos valores juntos en lugar de sustituirlos por las cabeceras de tu navegador habitual.

Las respuestas de la API, las cabeceras generadas y la respuesta del destino permanecen en un directorio temporal privado en lugar de imprimirse. No las incluyas en los registros habituales ni actives el trazado del shell.

Guarda los ID de recuperación impresos. Volver a ejecutar el script genera un nuevo requestId; no es un intento de recuperación. Para recuperar la creación, reutiliza el ID de solicitud guardado con exactamente los datos originales de la tarea. El script elimina su archivo de entrada al salir, así que conserva esos datos de forma segura si necesitas reconstruir la solicitud.

El POST agota el tiempo de espera antes de devolver un ID de tarea.

Que se agote el tiempo de espera de conexión no demuestra que la creación de la tarea haya fallado.

Prueba esto: Envía la misma solicitud de tarea con el requestId guardado. Unos datos de entrada idénticos recuperan la tarea existente; cambiar los datos al reutilizar ese ID genera un conflicto.

Se agota el plazo local de consulta.

Usa el ID de tarea impreso para comprobar si la tarea existente sigue pendiente o en resolución.

Prueba esto: Reanuda las consultas GET para ese ID con otro plazo finito. No crees una tarea de reemplazo solo porque haya terminado la espera local.

Una solicitud a la API devuelve una respuesta HTTP que no indica éxito.

Las llamadas a la API usan --fail-with-body, por lo que cURL termina antes de que el script lea una carga útil de éxito.

Prueba esto: Para el diagnóstico, añade un controlador de errores HTTP que examine de forma privada el cuerpo de la respuesta guardada antes de la limpieza. Corrige el problema de la solicitud indicado en lugar de reintentar a ciegas con los mismos datos.

La tarea pasa a failed.

El ejemplo imprime un mensaje de fallo genérico; la respuesta también contiene errorCode y error.

Prueba esto: Inspecciona esos campos en la rama de fallo antes de la limpieza y deja de consultar esa tarea. Usa la causa indicada para decidir qué cambiar. Las resoluciones fallidas se reembolsan.