cURL से Kasada हेडर जनरेट करें

स्क्रिप्ट के लिए Bash, cURL 7.76 या बाद का संस्करण, jq और openssl ज़रूरी हैं। SOLVETHREE_API_KEY को अपने वर्कस्पेस की API कुंजी पर और SOLVETHREE_PROXY को अपने HTTP या HTTPS प्रॉक्सी URL पर सेट करें। API कुंजी सर्वर-साइड रखें और शेल ट्रेसिंग बंद रखें।

यह उदाहरण पूरे समय एक ही प्रॉक्सी उपयोग करता है। Kasada अनुरोध में type, url और proxy या proxyCandidates में से ठीक एक ज़रूरी है; इसमें site या action जैसे reCAPTCHA फ़ील्ड, session या कस्टम ब्राउज़र पहचान फ़ील्ड शामिल नहीं होने चाहिए। Kasada अनुरोध अनुबंध देखें।

#!/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":"KasadaTask","url":"https://www.ticketmaster.com/","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")
jq -r '.solution.headers | to_entries[] | "\(.key): \(.value)"' "$work/result.json" > "$work/target-headers"
curl --silent --show-error --max-time 30 --proxy "$SOLVETHREE_PROXY" \
  --header @"$work/target-headers" --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.

टास्क बॉडी और अंतिम cURL कॉल, दोनों में उदाहरण वाले टारगेट URL को इच्छित समर्थित वर्कफ़्लो URL से बदलें। एक URL के लिए हल करवाकर परिणाम किसी असंबंधित टारगेट पर सबमिट न करें।

स्क्रिप्ट Bearer हेडर से प्रमाणीकरण करती है, एक टास्क बनाती है और केवल उसकी लौटाई गई ID की पोलिंग करती है। बनाने वाले अनुरोध का टाइमआउट 30 सेकंड है; पोलिंग में 180 सेकंड की स्थानीय समय-सीमा और सीमित GET अनुरोध उपयोग होते हैं। ये स्क्रिप्ट की सीमाएँ हैं, हल होने के समय की गारंटी नहीं। स्वचालित रीट्राई या रीडायरेक्ट का अनुसरण सक्षम नहीं है।

pending और solving का मतलब है कि पोलिंग जारी रखें। केवल ready में उपयोग योग्य समाधान होता है। स्क्रिप्ट jq से मूल solution.headers ऑब्जेक्ट पढ़ती है और हर एंट्री को हेडर फ़ाइल की एक पंक्ति में बदलती है; यह कोई एक हेडर नहीं चुनती और न ही टास्क ID को समाधान मानती है।

अंतिम अनुरोध उस हेडर फ़ाइल को लोड करता है, solution.userAgent और solution.secChUa सेट करता है और मूल प्रॉक्सी का उपयोग करता है। अपने सामान्य ब्राउज़र हेडर लगाने के बजाय इन वैल्यू को साथ रखें।

API रिस्पॉन्स, जनरेट किए गए हेडर और टारगेट रिस्पॉन्स प्रिंट होने के बजाय एक निजी अस्थायी डायरेक्टरी में रहते हैं। इन्हें नियमित लॉग से बाहर रखें और शेल ट्रेसिंग सक्षम न करें।

प्रिंट की गई रिकवरी ID सेव करें। स्क्रिप्ट दोबारा चलाने से नया requestId बनता है; यह रिकवरी का प्रयास नहीं है। टास्क बनाने की प्रक्रिया रिकवर करने के लिए सेव की गई अनुरोध ID को ठीक मूल टास्क इनपुट के साथ दोबारा उपयोग करें। स्क्रिप्ट बाहर निकलते समय अपनी इनपुट फ़ाइल मिटा देती है, इसलिए यदि अनुरोध दोबारा बनाना हो तो उन इनपुट को सुरक्षित रखें।

टास्क ID लौटने से पहले POST का टाइमआउट हो जाता है।

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

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

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

प्रिंट की गई टास्क ID से जाँचें कि मौजूदा टास्क अभी भी लंबित है या हल किया जा रहा है।

यह आज़माएँ: एक और सीमित समय-सीमा के साथ उस ID के लिए GET पोलिंग फिर शुरू करें। केवल स्थानीय प्रतीक्षा समाप्त होने के कारण उसकी जगह नया टास्क न बनाएँ।

API अनुरोध गैर-सफल HTTP रिस्पॉन्स लौटाता है।

API कॉल में --fail-with-body उपयोग होता है, इसलिए स्क्रिप्ट के सफलता पेलोड पढ़ने से पहले cURL बंद हो जाता है।

यह आज़माएँ: समस्या का निदान करने के लिए ऐसा HTTP-त्रुटि हैंडलर जोड़ें जो सफ़ाई से पहले सेव की गई रिस्पॉन्स बॉडी की निजी तौर पर जाँच करे। बिना बदलाव वाले इनपुट से आँख मूँदकर दोबारा कोशिश करने के बजाय बताई गई अनुरोध समस्या ठीक करें।

टास्क की स्थिति failed हो जाती है।

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

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