Corriger un cookie TMPT qui n’est pas envoyé correctement

Commencez avec une tâche dont le statut est ready. Si la tâche est failed, arrêtez de l’interroger et inspectez errorCode et error ; aucune solution utilisable ne peut être jointe.

La requête sortante ne contient aucun cookie tmpt.

Comparez le nom d’hôte et le chemin réels de la requête avec le domaine et le chemin de l’entrée du magasin de cookies. Vérifiez si une redirection a modifié la destination.

Essayez ceci : Définissez le cookie avec une portée correspondant à la requête cible prévue. Inspectez les redirections avant de les suivre ; n’élargissez pas le domaine du cookie simplement pour le faire apparaître.

Le cookie contient du JSON, un ID de tâche ou un préfixe tmpt= répété.

Inspectez la valeur affectée au cookie, pas seulement la présence d’un en-tête Cookie.

Essayez ceci : Dans un magasin de cookies, utilisez tmpt comme nom et solution.token comme valeur. Pour un en-tête Cookie explicite, associez ce nom à la valeur brute une seule fois.

La requête sortante contient plusieurs valeurs tmpt.

Recherchez un ancien en-tête Cookie explicite et des entrées du magasin de cookies ayant des domaines ou des chemins différents.

Essayez ceci : Remplacez l’entrée visée et supprimez les entrées TMPT obsolètes de cette session. Ne concaténez pas les anciennes et les nouvelles valeurs, et n’ajoutez pas une autre paire tmpt.

tmpt est présent, mais d’autres cookies de session requis ont disparu.

Vérifiez si vous avez créé une nouvelle session ou remplacé l’intégralité de l’en-tête Cookie par tmpt uniquement.

Essayez ceci : Conservez les autres cookies requis par la session prévue, avec une seule valeur TMPT à jour.

Ces exemples font suite à l’exemple de tâche TMPT. Ils attendent un result prêt et la request d’origine, créée avec un seul proxy. Tous deux réutilisent ce proxy, l’URL cible et les valeurs userAgent et secChUa renvoyées.

# Continue after the TMPT example. Install requests separately.
from urllib.parse import urlsplit
import requests

solution = result["solution"]
session = requests.Session()
session.headers.update({
    "User-Agent": solution["userAgent"],
    "sec-ch-ua": solution["secChUa"],
})
session.cookies.set("tmpt", solution["token"],
                    domain=urlsplit(request["url"]).hostname, path="/")
response = session.get(
    request["url"],
    proxies={"http": request["proxy"], "https": request["proxy"]},
    timeout=30,
    allow_redirects=False,
)
print("Target HTTP status:", response.status_code)

// Continue after the TMPT example. Install undici separately: npm install undici@7.
import { fetch, ProxyAgent } from 'undici';

const headers = new Headers({
  'user-agent': result.solution.userAgent,
  'sec-ch-ua': result.solution.secChUa,
});
headers.set('cookie', `tmpt=${result.solution.token}`);
// Merge any other cookies your application requires, with one current tmpt value.
const dispatcher = new ProxyAgent(request.proxy);
try {
  const response = await fetch(request.url, {
    dispatcher, headers, redirect: 'manual',
    signal: AbortSignal.timeout(30_000),
  });
  console.log('Target HTTP status:', response.status);
  await response.arrayBuffer();
} finally {
  await dispatcher.close();
}

L’exemple Python définit le cookie pour le nom d’hôte cible avec le chemin /. Il crée une nouvelle Session. Si votre application nécessite une session de connexion existante, utilisez cette session et remplacez son ancienne entrée TMPT.

L’exemple Node.js prépare un en-tête Cookie explicite avec une seule valeur TMPT. Intégrez à cet en-tête tous les autres cookies requis de la même session, sans ajouter d’ancienne valeur TMPT. Contrairement à un magasin de cookies, un en-tête préparé manuellement ne sélectionne pas les cookies par domaine et chemin ; utilisez-le uniquement pour la destination prévue.

Les deux exemples ne suivent pas les redirections afin que vous puissiez inspecter la première réponse de la cible. Ils affichent son statut HTTP ; ils ne prouvent pas que la cible a accepté le cookie ou effectué l’action prévue.

• Faites correspondre la tâche à la requête. TicketmasterTmptTask utilise l’url cible exacte : Event prend l’URL de l’événement, tandis que Login prend l’URL d’entrée de connexion. Un cookie généré pour un autre contexte ne dispense pas de corriger ces données d’entrée.
• Utilisez les valeurs userAgent et secChUa renvoyées avec le proxy ayant réussi. N’effectuez pas la résolution via un proxy pour ensuite envoyer la requête cible via un autre. Si vous avez fourni proxyCandidates, utilisez le proxy ayant réussi plutôt qu’un candidat arbitraire.
• Ne traitez pas la valeur brute comme une session de navigateur enregistrée. Elle ne conserve pas un enregistrement complet du cookie et ne définit pas de date d’expiration. Aucune durée de vie fixe du cookie ne peut être déduite de solution.token.

Si le cookie est envoyé correctement, mais que Ticketmaster renvoie toujours une erreur 403, poursuivez avec les vérifications des rejets Ticketmaster.