修复 TMPT cookie 发送不正确的问题

从状态为 ready 的任务开始。如果任务状态为 failed，停止轮询并检查 errorCode 和 error；此时没有可附加的可用解答。

发出的请求中没有 tmpt cookie。

将请求的实际主机名和路径与 cookie 容器条目的域和路径进行比较。检查重定向是否改变了目标地址。

试试这样做： 设置 cookie 时，使其作用域与预期的目标请求匹配。跟随重定向前先进行检查；不要仅为让 cookie 出现在请求中而扩大其域范围。

cookie 包含 JSON、任务 ID 或重复的 tmpt= 前缀。

检查赋给 cookie 的值，而不只是确认 Cookie 请求头是否存在。

试试这样做： 使用 cookie 容器时，以 tmpt 为名称，以 solution.token 为值。显式设置 Cookie 请求头时，只将该名称与原始值配对一次。

发出的请求包含多个 tmpt 值。

查找旧的显式 Cookie 请求头，以及域或路径不同的 cookie 容器条目。

试试这样做： 替换目标条目，并从该会话中移除不再使用的 TMPT 条目。不要拼接新旧值，也不要再追加一组 tmpt 名值对。

tmpt 存在，但其他必需的会话 cookie 消失了。

检查是否创建了新会话，或将整个 Cookie 请求头替换为仅包含 tmpt 的内容。

试试这样做： 保留预期会话所需的其他 cookie，并仅保留一个当前的 TMPT 值。

这些示例承接 TMPT 任务示例。它们需要一个已就绪的 result，以及使用单个 proxy 创建的原始 request。两个示例都复用该代理、目标 URL，以及返回的 userAgent 和 secChUa。

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

Python 示例为目标主机名设置 cookie，路径为 /。它会创建一个新的 Session。如果应用需要现有的登录会话，请使用该会话，并替换其中旧的 TMPT 条目。

Node.js 示例准备了一个显式 Cookie 请求头，其中包含一个 TMPT 值。将同一会话所需的其他 cookie 合并到该请求头中，但不要追加旧的 TMPT 值。与 cookie 容器不同，手动准备的请求头不会按域和路径选择 cookie；仅将其用于预期的目标地址。

两个示例都不跟随重定向，以便你检查目标的首次响应。它们会打印该响应的 HTTP 状态；这并不能证明目标接受了 cookie 或完成了预期操作。

• 确保任务与请求匹配。TicketmasterTmptTask 使用确切的目标 url：Event 使用活动 URL，Login 使用登录入口 URL。为其他上下文生成的 cookie 不能替代对这些输入的修正。
• 将返回的 userAgent 和 secChUa 与成功的代理配合使用。不要通过一个代理求解，再通过另一个代理发送目标请求。如果提供了 proxyCandidates，请使用成功的代理，而不是任意选择一个候选代理。
• 不要将原始值视为保存的浏览器会话。它既不保留完整的 cookie 记录，也不确定过期时间。无法从 solution.token 推断出固定的 cookie 有效期。

如果 cookie 发送正确，但 Ticketmaster 仍返回 403，请继续参阅 Ticketmaster 拒绝问题检查。