cURL से TMPT कुकी का अनुरोध करें और उसका उपयोग करें

• Event के लिए, url को सटीक इवेंट URL पर सेट करें।
• Login के लिए, url को साइन-इन के प्रवेश URL पर सेट करें।
• इस स्क्रिप्ट के लिए एक प्रॉक्सी दें। टारगेट को कुकी भेजते समय यह उसी प्रॉक्सी का दोबारा उपयोग करती है।
• TMPT टास्क में site, recaptchaType या session शामिल न करें।

उदाहरण में Login और प्लेसहोल्डर के तौर पर Ticketmaster होमपेज URL उपयोग होता है। टास्क 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 से केवल उसकी लौटाई गई ID की पोलिंग करती है। pending और solving दोनों का मतलब है कि पोलिंग जारी रहनी चाहिए; केवल ready उपयोग योग्य समाधान देता है।

बनाने वाले अनुरोध का टाइमआउट 30 सेकंड है। पोलिंग लूप हर पोल से पहले 180 सेकंड की स्थानीय समय-सीमा जाँचता है और हर पोलिंग अनुरोध को अधिकतम 25 सेकंड तक सीमित करता है। उस समय-सीमा तक पहुँचने पर यह स्क्रिप्ट रुक जाती है; इससे यह स्थापित नहीं होता कि रिमोट टास्क विफल हो गया।

टारगेट अनुरोध के लिए, cURL का --cookie विकल्प मूल टोकन से Cookie हेडर बनाता है। स्क्रिप्ट solution.userAgent, solution.secChUa और मूल प्रॉक्सी भी लागू करती है। यह न तो स्वचालित रीट्राई सक्षम करती है और न ही रीडायरेक्ट का अनुसरण।

टास्क ID प्रिंट होने से पहले टास्क बनाने का अनुरोध टाइमआउट हो जाता है।

कनेक्शन टाइमआउट यह साबित नहीं करता कि API टास्क बनाने में विफल रही।

यह आज़माएँ: प्रिंट किया गया requestId और मूल टास्क इनपुट संभालकर रखें। नया तार्किक टास्क बनाने के बजाय मौजूदा टास्क रिकवर करने के लिए उसी requestId के साथ वही इनपुट दोबारा सबमिट करें। ID का दोबारा उपयोग करते हुए इनपुट बदलने से टकराव होता है।

API कॉल गैर-सफल HTTP रिस्पॉन्स लौटाती है।

यह HTTP स्तर की त्रुटि है, टास्क स्टेटस नहीं। स्क्रिप्ट का --fail-with-body विकल्प रिस्पॉन्स बॉडी सेव करते हुए कॉल को विफल करता है।

यह आज़माएँ: अस्थायी फ़ाइलों की सफ़ाई से पहले सेव किए गए API रिस्पॉन्स की जाँच करें। रिस्पॉन्स को सफल टास्क मानकर पार्स करने या बिना बदलाव वाले इनपुट को आँख मूँदकर दोहराने के बजाय बताई गई समस्या ठीक करें।

स्क्रिप्ट बताती है कि सॉल्वर टास्क विफल हो गया।

स्क्रिप्ट एक सामान्य विफलता संदेश प्रिंट करती है; विफल टास्क में errorCode और error होते हैं।

यह आज़माएँ: प्रिंट की गई टास्क ID का उपयोग करके टास्क प्राप्त करें और उन फ़ील्ड की जाँच करें। विफल टास्क की पोलिंग बंद करें। विफल हल के लिए भुगतान वापस किया जाता है।

स्थानीय पोलिंग समय-सीमा समाप्त हो जाती है।

टास्क अभी भी लंबित हो सकता है या उसे हल किया जा रहा हो सकता है।

यह आज़माएँ: प्रिंट की गई टास्क ID से टास्क प्राप्त करना फिर शुरू करें। केवल स्थानीय स्क्रिप्ट के इंतज़ार बंद करने के कारण दूसरा टास्क न बनाएँ।

टास्क तैयार है, लेकिन लक्ष्य अनुरोध अस्वीकार कर देता है।

केवल सॉल्वर स्टेटस नहीं, बल्कि आउटगोइंग कुकी, यूज़र एजेंट, क्लाइंट हिंट, प्रॉक्सी और टारगेट URL की भी जाँच करें।

यह आज़माएँ: पुष्टि करें कि tmpt कुकी में solution.token है, बिना Set-Cookie प्रीफ़िक्स या एट्रिब्यूट के। लौटाई गई पहचान और मूल प्रॉक्सी का उपयोग करें, और जाँचें कि टारगेट URL इच्छित वर्कफ़्लो से मेल खाता है।