Solicite e use um cookie TMPT com cURL

• Para Event, defina url como a URL exata do evento.
• Para Login, defina url como a URL de entrada do login.
• Forneça um único proxy para este script. Ele usa esse proxy novamente ao enviar o cookie ao destino.
• Não inclua site, recaptchaType ou session na tarefa TMPT.

O exemplo usa Login e uma URL ilustrativa da página inicial do Ticketmaster. Substitua a URL da tarefa e o destino cURL final pelas URLs reais do seu fluxo compatível. Se estiver solicitando um cookie de evento, altere também a ação para Event.

Execute o script no servidor com 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. Mantenha o rastreamento do shell desativado: ele pode expor a chave, as credenciais do proxy e o 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.

O script autentica com uma chave Bearer, cria uma tarefa com POST /v1/tasks e depois consulta apenas o ID retornado com GET /v1/tasks/:id. Tanto pending quanto solving indicam que as consultas devem continuar; apenas ready fornece uma solução utilizável.

A criação tem um timeout de requisição de 30 segundos. O loop de consultas verifica um prazo local de 180 segundos antes de cada consulta e limita cada requisição de consulta a no máximo 25 segundos. Atingir esse prazo interrompe este script; isso não comprova que a tarefa remota falhou.

Na requisição ao destino, a opção --cookie do cURL monta o cabeçalho Cookie a partir do token bruto. O script também aplica solution.userAgent, solution.secChUa e o proxy original. Ele não ativa novas tentativas automáticas nem o acompanhamento de redirecionamentos.

A criação da tarefa atinge o timeout antes de imprimir um ID de tarefa.

Um timeout de conexão não comprova que a API falhou ao criar a tarefa.

Experimente: Guarde o requestId impresso e os dados de entrada originais da tarefa. Reenvie esses mesmos dados com esse requestId para recuperar a tarefa existente em vez de criar uma nova tarefa lógica. Alterar os dados ao reutilizar o ID gera um conflito.

Uma chamada à API retorna uma resposta HTTP sem sucesso.

Este é um erro da camada HTTP, não um status de tarefa. A opção --fail-with-body do script faz a chamada falhar, mas salva o corpo da resposta.

Experimente: Inspecione a resposta da API salva antes da limpeza dos arquivos temporários. Corrija o problema informado em vez de interpretar a resposta como uma tarefa bem-sucedida ou repetir às cegas os mesmos dados de entrada.

O script informa que a tarefa de resolução falhou.

O script imprime uma mensagem genérica de falha; a tarefa com falha contém errorCode e error.

Experimente: Recupere o ID de tarefa impresso e inspecione esses campos. Pare de consultar uma tarefa com falha. Resoluções com falha são reembolsadas.

O prazo local de consulta de status expira.

A tarefa ainda pode estar pendente ou em resolução.

Experimente: Retome a consulta usando o ID de tarefa impresso. Não crie outra tarefa apenas porque o script local parou de esperar.

A tarefa está pronta, mas o destino rejeita a requisição.

Inspecione o cookie de saída, o user agent, os client hints, o proxy e a URL de destino, não apenas o status da resolução.

Experimente: Confirme que o cookie tmpt contém solution.token, sem prefixo Set-Cookie nem atributos. Use a identidade retornada e o proxy original e verifique se a URL de destino corresponde ao fluxo pretendido.