TypeScript में CAPTCHA टास्क के परिणाम सुरक्षित ढंग से संभालें

इनपुट के लिए SDK से एक्सपोर्ट किया गया TaskRequest और रिस्पॉन्स के लिए TaskResult उपयोग करें। स्टेटस का टाइप नैरो करने से TypeScript अधूरे काम, विफलता और तैयार स्थिति में अंतर कर सकता है—बिना any या ऐसे कास्ट के जो कंपाइलर से केवल आप पर भरोसा करने को कहता है।

import { Solvethree, type TaskRequest, type TaskResult } from '@solvethree/sdk';
const client = new Solvethree({ apiKey: process.env.SOLVETHREE_API_KEY! });
const input: TaskRequest = { site: 'accounts.example.com', action: 'login', proxy: process.env.SOLVETHREE_PROXY! };
function inspect(result: TaskResult): void {
  switch (result.status) {
    case 'pending':
    case 'solving':
      console.log('Retrieve this task again:', result.id);
      return;
    case 'failed':
      console.error('Failed task:', result.id, result.errorCode);
      return;
    case 'ready':
      // Solution fields depend on the requested product; check optional fields.
      if (!result.solution.token || !result.solution.userAgent || !result.solution.secChUa) {
        throw new Error('Expected a complete reCAPTCHA solution');
      }
      console.log('Ready task:', result.id);
      // Submit token privately with its browser identity and original proxy.
      return;
  }
}
inspect(await client.createTask(input, { waitMs: 0 }));
// Save the returned ID and call getTask while pending/solving with a deadline.

यह उदाहरण एक टास्क बनाता है और तत्काल मिले रिस्पॉन्स की जाँच करता है। pending और solving का मतलब है कि उसे फिर से प्राप्त करें; failed पर प्रोसेसिंग रुकती है; ready पर समाधान की जाँच की जाती है। यदि आप ready शाखा को किसी हेल्पर में अलग करते हैं, तो उसके पैरामीटर के लिए एक्सपोर्ट किए गए ReadyTask टाइप का उपयोग करें। इससे स्टेटस का दायरा सीमित होता है, लेकिन हर प्रोडक्ट-विशिष्ट समाधान फ़ील्ड अनिवार्य नहीं हो जाता।

गार्ड टोकन और ब्राउज़र की पहचान के दोनों फ़ील्ड की जाँच करते हैं, क्योंकि यह इनपुट reCAPTCHA का अनुरोध करता है। वे यह साबित नहीं करते कि लक्ष्य टोकन स्वीकार करेगा। उदाहरण जानबूझकर टोकन प्रिंट नहीं करता।

• Node.js 22+ और API दस्तावेज़ों में बताए गए आधिकारिक SDK tarball इंस्टॉलेशन का उपयोग करें; यह न मानें कि npm रजिस्ट्री पर कोई रिलीज़ मौजूद है।
• सर्वर एनवायरनमेंट में SOLVETHREE_API_KEY और SOLVETHREE_PROXY सेट करें। ! असर्शन रनटाइम पर अनुपस्थित एनवायरनमेंट वेरिएबल की जाँच नहीं करते।
• accounts.example.com और login की जगह इच्छित होस्टनेम और ऐक्शन रखें। साइट के लिए वर्कस्पेस में पहले से एक सक्रिय प्रोफ़ाइल होनी चाहिए; साइट प्रोफ़ाइल सेटअप देखें।

यह उदाहरण पोलिंग का ज़िम्मा कॉलर पर छोड़ता है। टास्क बनाना उस लूप से बाहर रखें: createTask को दोबारा कॉल करके यह नहीं जाँचा जाता कि पहला टास्क पूरा हुआ है या नहीं।

1. 1.

   टास्क बनाने के परिणाम का ID सहेजें

   प्राप्त करने के लिए लौटाए गए ID का उपयोग करने से पहले जाँचें कि वह एक गैर-खाली स्ट्रिंग है। उसे मूल अनुरोध से जुड़ा रखें, क्योंकि सफल प्रॉक्सी चुनते समय भी आपको मूल अनुरोध चाहिए होगा।

2. 2.

   उसी टास्क को प्राप्त करें

   जब तक स्टेटस pending या solving है, एक स्थानीय समय-सीमा के भीतर सहेजे गए ID के साथ getTask कॉल करें। हर रिस्पॉन्स को प्रोसेस करने से पहले जाँचें कि उसका ID सहेजे गए ID से मेल खाता है। ID का मेल यह तय करता है कि आप किस टास्क को संभाल रहे हैं, यह नहीं कि वह सफल हुआ या नहीं।

3. 3.

   अंतिम परिणाम मिलने पर रुकें

   ready पर, अनुरोधित प्रोडक्ट के लिए ज़रूरी फ़ील्ड की पुष्टि करें। failed पर, errorCode और error दोनों की जाँच करें, फिर उस टास्क की पोलिंग बंद कर दें। अनुरोध की त्रुटियों को अलग से संभालें: प्राप्त करने का अनुरोध असफल होना अपने आप में टास्क की अंतिम विफलता नहीं है।

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

मूल अनुरोध के आधार पर हैंडलर चुनें, फिर अपेक्षित समाधान फ़ील्ड की जाँच करें। केवल टोकन की मौजूदगी से reCAPTCHA रिस्पॉन्स और TMPT कुकी के मान के बीच अंतर नहीं किया जा सकता।

स्टैंडअलोन Kasada फ़िलहाल www.ticketmaster.com पर HTTPS लक्ष्यों का समर्थन करता है, मनमानी साइटों का नहीं। इसका हेडर हैंडलर सार्वभौमिक Kasada इंटीग्रेशन नहीं है।

हर प्रोडक्ट के लिए, लौटाए गए userAgent और secChUa तथा सफल प्रॉक्सी के साथ सबमिट करें। प्रॉक्सी उम्मीदवारों के मामले में, पहले उम्मीदवार को सफल मानने के बजाय successfulProxy(originalTask, readyResult) का उपयोग करें। SDK आपकी ओर से लक्ष्य पर समाधान लागू नहीं करता, और ready इस बात की गारंटी नहीं देता कि बाद का वह अनुरोध स्वीकार होगा।