בקשה ושימוש בעוגיית TMPT באמצעות cURL

• עבור Event, הגדירו את url ככתובת המדויקת של האירוע.
• עבור Login, הגדירו את url ככתובת הכניסה לתהליך ההתחברות.
• ספקו פרוקסי יחיד לסקריפט הזה. הוא משתמש שוב בפרוקסי הזה בעת שליחת העוגייה ליעד.
• אל תכללו site,‏ recaptchaType או session במשימת TMPT.

הדוגמה משתמשת ב-Login ובכתובת דף הבית של Ticketmaster כמציין מקום. החליפו את כתובת המשימה ואת יעד ה-cURL הסופי בכתובות בפועל של התהליך הנתמך שלכם. אם אתם מבקשים עוגיית אירוע, שנו גם את הפעולה ל-Event.

הריצו את הסקריפט בצד השרת עם Bash,‏ cURL 7.76 ואילך, jq ו-openssl. הגדירו את SOLVETHREE_API_KEY כמפתח ה-API של סביבת העבודה ואת SOLVETHREE_PROXY ככתובת הפרוקסי שלכם. השאירו את מעקב פקודות המעטפת כבוי: הוא עלול לחשוף את המפתח, פרטי ההזדהות לפרוקסי והעוגייה.

#!/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.

הסקריפט מבצע אימות באמצעות מפתח Bearer, יוצר משימה אחת באמצעות POST /v1/tasks, ואז מתשאל רק את המזהה שהוחזר עבורה באמצעות GET /v1/tasks/:id. גם pending וגם solving מציינים שיש להמשיך בתשאול; רק ready מספק פתרון שמיש.

לבקשת היצירה יש זמן המתנה מרבי של 30 שניות. לולאת התשאול בודקת מגבלת זמן מקומית של 180 שניות לפני כל תשאול ומגבילה בקשות תשאול בודדות ל-25 שניות לכל היותר. הגעה למגבלת הזמן הזאת עוצרת את הסקריפט הזה; היא אינה מעידה שהמשימה המרוחקת נכשלה.

בבקשה ליעד, האפשרות --cookie של cURL בונה את כותרת Cookie מהטוקן הגולמי. הסקריפט מחיל גם את solution.userAgent,‏ solution.secChUa והפרוקסי המקורי. הוא אינו מפעיל ניסיונות חוזרים אוטומטיים או מעקב אחר הפניות.

יצירת המשימה חורגת מזמן ההמתנה לפני שמודפס מזהה משימה.

חריגה מזמן ההמתנה לחיבור אינה מוכיחה שה-API לא הצליח ליצור את המשימה.

כדאי לנסות: שמרו את requestId שהודפס ואת נתוני הקלט המקוריים של המשימה. שלחו שוב את אותם נתוני קלט עם אותו requestId כדי לשחזר את המשימה הקיימת במקום ליצור משימה לוגית חדשה. שינוי נתוני הקלט תוך שימוש חוזר במזהה גורם להתנגשות.

קריאת API מחזירה תגובת HTTP שאינה מציינת הצלחה.

זוהי שגיאה בשכבת ה-HTTP, לא סטטוס של משימה. האפשרות --fail-with-body של הסקריפט גורמת לקריאה להיכשל תוך שמירת גוף התגובה.

כדאי לנסות: בדקו את תגובת ה-API השמורה לפני ניקוי הקבצים הזמניים. תקנו את הבעיה שדווחה במקום לפענח את התגובה כמשימה שהצליחה או לחזור באופן עיוור על קלט ללא שינוי.

הסקריפט מדווח שמשימת הפתרון נכשלה.

הסקריפט מדפיס הודעת כשל כללית; המשימה שנכשלה מכילה errorCode ו-error.

כדאי לנסות: שלפו את המשימה באמצעות מזהה המשימה שהודפס ובדקו את השדות האלה. הפסיקו לתשאל משימה שנכשלה. על פתרונות שנכשלו ניתן החזר כספי.

מגבלת הזמן המקומית לתשאול פגה.

ייתכן שהמשימה עדיין ממתינה או נמצאת בתהליך פתרון.

כדאי לנסות: חדשו את השליפה באמצעות מזהה המשימה שהודפס. אל תיצרו משימה נוספת רק משום שהסקריפט המקומי הפסיק להמתין.

המשימה מוכנה, אבל היעד דוחה את הבקשה.

בדקו את העוגייה היוצאת, סוכן המשתמש, רמזי הלקוח, הפרוקסי וכתובת היעד — לא רק את סטטוס הפתרון.

כדאי לנסות: ודאו שעוגיית tmpt מכילה את solution.token, ללא קידומת Set-Cookie או מאפיינים. השתמשו בזהות שהוחזרה ובפרוקסי המקורי, ובדקו שכתובת היעד תואמת לתהליך המיועד.