Ein nicht korrekt gesendetes TMPT-Cookie korrigieren

Beginne mit einer Aufgabe, deren Status ready ist. Wenn die Aufgabe den Status failed hat, beende das Polling und prüfe errorCode und error; es gibt keine verwendbare Lösung zum Einfügen.

Die ausgehende Anfrage enthält keinen tmpt-Cookie.

Vergleiche den tatsächlichen Hostnamen und Pfad der Anfrage mit der Domain und dem Pfad des Eintrags im Cookie-Speicher. Prüfe, ob eine Weiterleitung das Ziel geändert hat.

Probiere Folgendes: Setze den Cookie mit einem Gültigkeitsbereich, der zur vorgesehenen Zielanfrage passt. Prüfe Weiterleitungen, bevor du ihnen folgst; erweitere nicht einfach die Domain des Cookies, nur damit er gesendet wird.

Der Cookie enthält JSON, eine Task-ID oder ein wiederholtes tmpt=-Präfix.

Prüfe den Wert, der dem Cookie zugewiesen wurde, nicht nur, ob ein Cookie-Header vorhanden ist.

Probiere Folgendes: Verwende in einem Cookie-Speicher tmpt als Namen und solution.token als Wert. Kombiniere bei einem expliziten Cookie-Header diesen Namen genau einmal mit dem unveränderten Wert.

Die ausgehende Anfrage enthält mehrere tmpt-Werte.

Suche nach einem alten expliziten Cookie-Header und Einträgen im Cookie-Speicher mit unterschiedlichen Domains oder Pfaden.

Probiere Folgendes: Ersetze den vorgesehenen Eintrag und entferne veraltete TMPT-Einträge aus dieser Sitzung. Verkette nicht den alten und den neuen Wert und hänge kein weiteres tmpt-Paar an.

tmpt ist vorhanden, aber andere erforderliche Sitzungscookies sind verschwunden.

Prüfe, ob du eine neue Sitzung erstellt oder den gesamten Cookie-Header durch ausschließlich tmpt ersetzt hast.

Probiere Folgendes: Behalte die anderen für die vorgesehene Sitzung erforderlichen Cookies zusammen mit einem aktuellen TMPT-Wert bei.

Diese Beispiele schließen an das TMPT-Aufgabenbeispiel an. Sie erwarten ein bereites result und den ursprünglichen request, der mit einem einzelnen proxy erstellt wurde. Beide verwenden diesen Proxy, die Ziel-URL und die zurückgegebenen Werte userAgent und secChUa erneut.

# 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();
}

Das Python-Beispiel setzt den Cookie für den Zielhostnamen mit dem Pfad /. Es erstellt eine neue Session. Wenn deine Anwendung eine bestehende Anmeldesitzung benötigt, verwende diese Sitzung und ersetze stattdessen ihren alten TMPT-Eintrag.

Das Node.js-Beispiel bereitet einen expliziten Cookie-Header mit einem TMPT-Wert vor. Füge alle anderen erforderlichen Cookies derselben Sitzung in diesen Header ein, ohne einen alten TMPT-Wert anzuhängen. Anders als ein Cookie-Speicher wählt ein manuell vorbereiteter Header Cookies nicht nach Domain und Pfad aus; verwende ihn nur für das vorgesehene Ziel.

Beide Beispiele folgen Weiterleitungen nicht, damit du die erste Antwort des Ziels prüfen kannst. Sie geben deren HTTP-Status aus; sie bestätigen nicht, dass das Ziel den Cookie akzeptiert oder die vorgesehene Aktion abgeschlossen hat.

• Stimme die Aufgabe auf die Anfrage ab. TicketmasterTmptTask verwendet die genaue Ziel-url: Event benötigt die Event-URL, Login dagegen die Einstiegs-URL zur Anmeldung. Ein Cookie, der für einen anderen Kontext generiert wurde, ersetzt nicht die Korrektur dieser Eingaben.
• Verwende die zurückgegebenen Werte userAgent und secChUa zusammen mit dem erfolgreichen Proxy. Löse nicht über einen Proxy und sende die Zielanfrage über einen anderen. Wenn du proxyCandidates angegeben hast, verwende den erfolgreichen Proxy, statt einen beliebigen Kandidaten auszuwählen.
• Behandle den unveränderten Wert nicht als gespeicherte Browsersitzung. Er bewahrt keinen vollständigen Cookie-Datensatz und legt keinen Ablaufzeitpunkt fest. Aus solution.token lässt sich keine feste Cookie-Lebensdauer ableiten.

Wenn der Cookie korrekt gesendet wird, Ticketmaster aber weiterhin 403 zurückgibt, fahre mit den Prüfungen bei einer Ablehnung durch Ticketmaster fort.