طلب ملف تعريف ارتباط TMPT واستخدامه عبر cURL

• بالنسبة إلى Event، اضبط url على عنوان URL الدقيق للفعالية.
• بالنسبة إلى Login، اضبط url على عنوان URL لمدخل تسجيل الدخول.
• وفّر وكيلاً واحداً لهذا السكربت. سيستخدمه مجدداً عند إرسال ملف تعريف الارتباط إلى الهدف.
• لا تُضمّن site أو recaptchaType أو session في مهمة TMPT.

يستخدم المثال Login وعنوان URL نائباً للصفحة الرئيسية في Ticketmaster. استبدل عنوان URL للمهمة وهدف cURL النهائي بعناوين URL الفعلية لسير عملك المدعوم. إذا كنت تطلب ملف تعريف ارتباط لفعالية، فغيّر الإجراء أيضاً إلى Event.

شغّل السكربت على جانب الخادم باستخدام Bash وcURL 7.76 أو أحدث وjq وopenssl. اضبط SOLVETHREE_API_KEY على مفتاح API لمساحة عملك، وSOLVETHREE_PROXY على عنوان URL للوكيل لديك. أبقِ تتبّع الصدفة معطّلاً، إذ قد يكشف المفتاح وبيانات اعتماد الوكيل وملف تعريف الارتباط.

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

جرّب هذا: استخدم معرّف المهمة المطبوع لجلبها وفحص هذين الحقلين. أوقف الاستعلام الدوري عن المهمة الفاشلة. تُردّ رسوم عمليات الحل الفاشلة.

تنتهي المهلة المحلية للاستعلام الدوري.

قد تكون المهمة لا تزال قيد الانتظار أو الحل.

جرّب هذا: استأنف الجلب باستخدام معرّف المهمة المطبوع. لا تنشئ مهمة أخرى لمجرد أن السكربت المحلي توقف عن الانتظار.

المهمة جاهزة، لكن الموقع المستهدف يرفض الطلب.

افحص ملف تعريف الارتباط الصادر ووكيل المستخدم وتلميحات العميل والوكيل وعنوان URL المستهدف، لا حالة أداة الحل وحدها.

جرّب هذا: تأكد من أن ملف تعريف الارتباط tmpt يحتوي على solution.token، دون بادئة Set-Cookie أو سمات. استخدم الهوية المُعادة والوكيل الأصلي، وتحقق من أن عنوان URL المستهدف يطابق سير العمل المقصود.