कार्य तैयार है। reCAPTCHA टोकन अस्वीकार क्यों हो रहा है?

{
  "id": "example-task",
  "status": "ready",
  "solution": {
    "token": "EXAMPLE_TOKEN",
    "userAgent": "EXAMPLE_USER_AGENT",
    "secChUa": "EXAMPLE_CLIENT_HINTS"
  }
}

इस उदाहरण में, जहाँ भी लक्ष्य अपने reCAPTCHA टोकन की अपेक्षा करता है, वहाँ solution.token का मान भेजना है। id solvethree टास्क की पहचान करता है; यह टोकन नहीं है। पूरा समाधान ऑब्जेक्ट भी न भेजें।

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

भेजा गया टोकन सही है, लेकिन लक्ष्य फिर भी उसे अस्वीकार करता है।

टास्क की साइट के होस्टनाम की तुलना सुरक्षित अनुरोध के होस्टनाम से करें। जाँचें कि कहीं सबडोमेन या एनवायरनमेंट अलग तो नहीं है।

यह आज़माएँ: इच्छित होस्टनाम के लिए टोकन का अनुरोध करें और उसे उसी लक्ष्य पर सबमिट करें। लक्ष्य साइट के लिए आपकी वर्कस्पेस में एक सक्रिय प्रोफ़ाइल उपलब्ध होनी चाहिए।

एक इंटरैक्शन के लिए अनुरोधित टोकन दूसरे इंटरैक्शन में इस्तेमाल किया जा रहा है।

टास्क के action की तुलना इस सुरक्षित अनुरोध के लिए अपेक्षित सटीक action से करें।

यह आज़माएँ: आप जो इंटरैक्शन सबमिट कर रहे हैं, उससे जुड़े action का इस्तेमाल करें।

इंटीग्रेशन गलत reCAPTCHA वेरिएंट का इस्तेमाल कर रहा है।

टास्क अनुरोध में recaptchaType जाँचें। इसका डिफ़ॉल्ट enterprise-v3 है; गेटवे v3 भी स्वीकार करता है।

यह आज़माएँ: लक्ष्य के प्रोडक्ट का स्पष्ट रूप से मिलान करें। Enterprise v3 के लिए enterprise-v3 इस्तेमाल करें।

क्लासिक reCAPTCHA और reCAPTCHA Enterprise, दोनों के वेबसाइट रिस्पॉन्स टोकन दो मिनट बाद समाप्त हो जाते हैं और केवल एक बार इस्तेमाल किए जा सकते हैं। क्लासिक टोकन का सत्यापन एक बार किया जा सकता है; Enterprise टोकन का आकलन एक बार किया जा सकता है। तैयार टोकन का भंडार रखने के बजाय सुरक्षित अनुरोध भेजने के समय के करीब ही सॉल्व करें।

• यदि सबमिशन में देरी होती है, तो जाँचें कि सॉल्व करने और टोकन भेजने के बीच कितना समय बीता।
• यदि टोकन का सत्यापन या आकलन पहले ही हो चुका है, तो उसे किसी दूसरे सबमिशन के लिए दोबारा इस्तेमाल न करें।
• लक्ष्य पर भेजने से पहले केवल टोकन की जाँच के लिए अलग से सत्यापन या Enterprise आकलन न चलाएँ। इस परीक्षण में उसका एकमात्र उपयोग खर्च हो सकता है।

सॉल्व सफल होता है, लेकिन सबमिशन किसी दूसरे कनेक्शन से होता है।

सॉल्व में सफलतापूर्वक इस्तेमाल हुई प्रॉक्सी की तुलना सुरक्षित अनुरोध में इस्तेमाल हुई प्रॉक्सी से करें। यदि आपने proxyCandidates दिया है, तो यह न मानें कि पहला विकल्प सफल हुआ था।

यह आज़माएँ: सफल प्रॉक्सी के ज़रिए सबमिट करें। सॉल्व और सबमिशन के बीच IP बदलने से अनुरोध विफल हो सकता है।

सबमिट करने वाला क्लाइंट अपने डिफ़ॉल्ट ब्राउज़र हेडर इस्तेमाल कर रहा है।

भेजे जा रहे User-Agent और Sec-CH-UA मानों की तुलना solution.userAgent और solution.secChUa से करें।

यह आज़माएँ: लौटाई गई ब्राउज़र पहचान को सफल प्रॉक्सी के साथ इस्तेमाल करें। टोकन को असंबंधित user-agent या client-hint मानों के साथ न मिलाएँ।

लक्ष्य के HTTP स्टेटस के साथ उसकी रिस्पॉन्स बॉडी भी जाँचें। केवल 403 से यह पता नहीं चलता कि किस सुरक्षा व्यवस्था ने अनुरोध अस्वीकार किया। दूसरे टोकन का अनुरोध करने से पहले स्पष्ट टोकन त्रुटि या hostname/action में अंतर खोजें।

यदि सत्यापन के विवरण उपलब्ध हैं, तो क्लासिक reCAPTCHA का success परिणाम और लौटाई गई संदर्भ/त्रुटि जानकारी जाँचें। Enterprise के लिए टोकन की वैधता और आकलन के संबंधित कारण जाँचें। यह न मानें कि केवल स्कोर ही अस्वीकृति का कारण बताता है: आकलन का इस्तेमाल कैसे करना है, यह वेबसाइट तय करती है।

यदि कारण अब भी पता न चले, तो [email protected] से संपर्क करें और टास्क ID, इस्तेमाल किया गया हो तो requestId, प्रोडक्ट, टाइमस्टैम्प, लक्ष्य hostname/action, HTTP स्टेटस या टास्क त्रुटि, और संवेदनशील जानकारी हटाकर रिस्पॉन्स का विवरण दें। API कुंजियाँ, प्रॉक्सी पासवर्ड, टोकन, कुकी और ग्राहक डेटा हटा दें।