Make में CAPTCHA टास्क API का उपयोग करें

सबसे पहले, अपने वर्कस्पेस में लक्षित होस्टनेम के लिए सक्रिय प्रोफ़ाइल सेट अप करें। site और action भेजने से प्रोफ़ाइल नहीं बनती। अगर लक्ष्य अभी कॉन्फ़िगर नहीं है, तो साइट प्रोफ़ाइल सेटअप देखें।

1. 1.

   HTTP v4 प्रमाणीकरण कॉन्फ़िगर करें

   प्रमाणीकरण प्रकार API key चुनें और क्रेडेंशियल कीचेन बनाएँ। कुंजी का मान Bearer, उसके बाद एक स्पेस और आपकी वर्कस्पेस API कुंजी रखें, स्थान In the header और पैरामीटर नाम Authorization सेट करें। अनुमत सेवा ऑरिजिन को https://api.solvethree.com तक सीमित रखें। कुंजी को सिनेरियो डेटा से पास करने के बजाय कीचेन में रखें।

2. 2.

   अनुरोध सेटिंग दर्ज करें

   नीचे दिखाए गए मेथड, URL, क्वेरी पैरामीटर, हेडर और JSON बॉडी का इस्तेमाल करें। हर एक को मॉड्यूल के संबंधित फ़ील्ड में दर्ज करें। JSON अनुरोध सामग्री में केवल body की सामग्री जाती है; पूरा उदाहरण कॉन्फ़िगरेशन समझाने के लिए है, यह इम्पोर्ट करने योग्य Make ब्लूप्रिंट नहीं है।

{
  "method": "POST",
  "url": "https://api.solvethree.com/v1/tasks",
  "query": {
    "waitMs": "0"
  },
  "headers": {
    "Content-Type": "application/json"
  },
  "body": {
    "site": "accounts.example.com",
    "action": "login",
    "proxy": "http://USER:PASSWORD@PROXY:PORT",
    "requestId": "one-stable-id-for-this-logical-job"
  },
  "authentication": {
    "type": "API key",
    "Key": "Bearer YOUR_PRIVATE_WORKSPACE_KEY",
    "API key placement": "In the header",
    "API key parameter name": "Authorization",
    "Allowed service origins": [
      "https://api.solvethree.com"
    ]
  }
}

• site को कॉन्फ़िगर किए गए होस्टनेम से बदलें, पूरे URL से नहीं। action को लक्षित फ़्लो में इस्तेमाल होने वाले ऐक्शन पर सेट करें।
• proxy को अपने प्रॉक्सी URL से बदलें। अनुरोध में proxy या proxyCandidates में से ठीक एक होना ज़रूरी है; उदाहरण में एक प्रॉक्सी इस्तेमाल होती है।
• हर नए लॉजिकल जॉब को उसका अपना requestId दें और रिकवरी के लिए उसे संभालकर रखें। उदाहरण का मान एक प्लेसहोल्डर है, असंबंधित जॉब में दोबारा इस्तेमाल करने के लिए ID नहीं।
• इस reCAPTCHA अनुरोध में type या url न जोड़ें। recaptchaType छोड़ने पर इसका डिफ़ॉल्ट मान enterprise-v3 होता है।

टास्क सफलतापूर्वक बनने की प्रतिक्रिया के बाद, आगे काम करने से पहले लौटाई गई टास्क ID को लॉजिकल जॉब के साथ सहेजें। वह टास्क प्राप्त करने के लिए अलग HTTP अनुरोध मॉड्यूल जोड़ें।

टास्क की स्थिति के आधार पर रूट करने से पहले असफल HTTP प्रतिक्रियाएँ संभालें। HTTP त्रुटि और failed स्थिति वाला टास्क एक ही चीज़ नहीं हैं; अपठनीय या असफल प्रतिक्रिया को एक और pending परिणाम न मानें।

GET सफल होने के बाद, लौटाए गए status पर स्पष्ट फ़िल्टर वाला राउटर जोड़ें। हर सफल HTTP प्रतिक्रिया को समाधान वाले रूट पर न भेजें।

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

एक सरल, सीमित डिज़ाइन हर पोलिंग रन में एक GET करता है। अधूरा काम ऐसी जगह सहेजें जहाँ अगला रन उसे पढ़ सके; ऐसी टास्क ID पर निर्भर न रहें जो केवल मौजूदा एक्ज़ीक्यूशन में उपलब्ध हो।

1. 1.

   प्रवेश पाथ चुनें

   अगर जॉब के पास पहले से टास्क ID है, तो सीधे GET पर जाएँ। केवल ऐसा नया जॉब जिसके पास मौजूदा टास्क नहीं है, टास्क बनाने वाले पाथ में जाना चाहिए।

2. 2.

   अधूरे रन समाप्त करें

   pending या solving के लिए, टास्क ID संभालकर रखें और रन समाप्त करें। फिर शुरू करने पर उसी ID को प्राप्त करें। अंतिम स्थिति वाले टास्क को बंद के रूप में चिह्नित करें ताकि बाद के पोलिंग रन उनके परिणाम दोबारा प्रोसेस न करें।

3. 3.

   हर रिपीटर की सीमा तय करें

   अगर आप इसके बजाय रिपीटर जोड़ते हैं, तो उसकी अधिकतम संख्या सीमित रखें और सहेजी गई ID के लिए केवल GET दोहराएँ। ready या failed के बाद आगे की पोलिंग या परिणाम प्रोसेसिंग रोकें। दोहराव की सीमा पर पहुँचने का मतलब रुकना और ID संभालकर रखना है, बदले में नया टास्क बनाना नहीं।

इस reCAPTCHA अनुरोध के लिए, सबमिट किया जाने वाला मान solution.token है, टास्क ID नहीं। लक्षित साइट पर सबमिट करते समय लौटाई गई userAgent और secChUa ब्राउज़र पहचान का इस्तेमाल सफल प्रॉक्सी के साथ करें।

यह न मानें कि Make का HTTP मॉड्यूल उस अंतिम अनुरोध के लिए सॉल्वर की ग्राहक प्रॉक्सी इस्तेमाल कर सकता है। तैयार परिणाम ऐसे क्लाइंट को दें जो ज़रूरी प्रॉक्सी और ब्राउज़र पहचान का समर्थन करता हो। ready का मतलब है कि समाधान जनरेट हो गया; उसे स्वीकार किया गया या नहीं, यह बाद के सबमिशन पर लक्ष्य की प्रतिक्रिया से तय होता है।