Gere cabeçalhos Kasada com cURL

O script exige Bash, cURL 7.76 ou posterior, jq e openssl. Defina SOLVETHREE_API_KEY como a chave de API do seu workspace e SOLVETHREE_PROXY como a URL do seu proxy HTTP ou HTTPS. Mantenha a chave de API no servidor e o rastreamento do shell desativado.

Este exemplo usa um único proxy em todo o fluxo. Uma requisição Kasada exige type, url e exatamente um dos campos proxy ou proxyCandidates; ela não deve incluir campos de reCAPTCHA, como site ou action, um session ou campos personalizados de identidade de navegador. Consulte o contrato de requisição 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.

Substitua a URL de destino do exemplo, tanto no corpo da tarefa quanto na chamada cURL final, pela URL pretendida do fluxo compatível. Não resolva para uma URL e envie o resultado a um destino não relacionado.

O script autentica com um cabeçalho Bearer, cria uma tarefa e consulta apenas o ID retornado. A criação tem um timeout de requisição de 30 segundos; as consultas usam um prazo local de 180 segundos e requisições GET com limites. Esses são limites do script, não garantias de tempo de resolução. Nem novas tentativas automáticas nem o acompanhamento de redirecionamentos estão ativados.

pending e solving indicam que as consultas devem continuar. Apenas ready contém uma solução utilizável. O script lê o objeto bruto solution.headers com jq e converte cada entrada em uma linha do arquivo de cabeçalhos; ele não seleciona um único cabeçalho nem trata o ID da tarefa como a solução.

A requisição final carrega esse arquivo de cabeçalhos, define solution.userAgent e solution.secChUa e usa o proxy original. Mantenha esses valores juntos em vez de substituí-los pelos cabeçalhos habituais do seu navegador.

As respostas da API, os cabeçalhos gerados e a resposta do destino ficam em um diretório temporário privado em vez de serem impressos. Mantenha-os fora dos logs de rotina e não ative o rastreamento do shell.

Salve os IDs de recuperação impressos. Executar o script novamente gera um novo requestId; isso não é uma tentativa de recuperação. Para recuperar a criação, reutilize o ID de requisição salvo com exatamente os dados de entrada originais da tarefa. O script exclui seu arquivo de entrada ao encerrar, portanto guarde esses dados com segurança se precisar reconstruir a requisição.

O POST atinge o timeout antes de retornar um ID de tarefa.

Um timeout de conexão não comprova que a criação da tarefa falhou.

Experimente: Envie a mesma requisição de tarefa com o requestId salvo. Dados de entrada idênticos recuperam a tarefa existente; alterar os dados ao reutilizar esse ID gera um conflito.

O prazo local de consulta de status expira.

Use o ID de tarefa impresso para verificar se a tarefa existente ainda está pendente ou em resolução.

Experimente: Retome as consultas GET para esse ID com outro prazo finito. Não crie uma substituta apenas porque a espera local terminou.

Uma requisição à API retorna uma resposta HTTP sem sucesso.

As chamadas à API usam --fail-with-body, portanto o cURL encerra antes que o script leia um payload de sucesso.

Experimente: Para diagnóstico, adicione um manipulador de erros HTTP que examine o corpo da resposta salvo de forma privada antes da limpeza. Corrija o problema informado na requisição em vez de tentar novamente às cegas com os mesmos dados de entrada.

A tarefa chega ao status failed.

O exemplo imprime uma mensagem genérica de falha; a resposta também contém errorCode e error.

Experimente: Inspecione esses campos no bloco de tratamento de falha antes da limpeza e depois pare de consultar essa tarefa. Use a causa informada para decidir o que alterar. Resoluções com falha são reembolsadas.