reCAPTCHA कॉलबैक कैसे खोजें और टोकन हैंडलिंग की जाँच कैसे करें

TL;DR

• reCAPTCHA कॉलबैक वह एप्लिकेशन कोड है जो परिणाम प्राप्त होने पर या किसी विजेट इवेंट पर चलता है; यह सर्वर‑साइड वेरिफिकेशन स्टेप नहीं है।
• पहले मौजूदा विजेट के data-callback एट्रिब्यूट को देखें, फिर उस कॉन्फ़िगरेशन को जाँचें जो पेज पर grecaptcha.render में पास की गई है, जब पेज एक्सप्लिसिट रेंडरिंग का उपयोग करता है।
• reCAPTCHA v3 के लिए, grecaptcha.execute के परिणाम से जुड़े हैंडलर को भी जाँचें; हर इंटीग्रेशन एक नाम दिया हुआ ग्लोबल कॉलबैक एक्सपोज़ नहीं करता।
• कॉपी किए गए इंटरनल ऑब्जेक्ट पाथ पर निर्भर होने के बजाय, ब्राउज़र डिबगिंग का उपयोग करके अपनी एप्लिकेशन के हैंडलर और सबमिशन रिक्वेस्ट की फ़्लो को फ़ॉलो करें।
• कॉलबैक का सफलतापूर्वक चलना यह सिद्ध नहीं करता कि सर्वर ने टोकन स्वीकार कर लिया या इरादा की गई प्रक्रिया पूरी कर दी।

कई बार CAPTCHA सॉल्यूशन मौजूद होता है, फिर भी फ़ॉर्म में कोई बदलाव नहीं दिखता। एक संभव कारण यह है कि एप्लिकेशन किसी रिज़ल्ट हैंडलर से अपनी स्टेट अपडेट या अगली रिक्वेस्ट सबमिट होने की अपेक्षा करता है। उस हैंडलर को ढूँढने से मिसिंग स्टेप समझ में आता है, लेकिन इसका मतलब यह नहीं कि हर पेज पर वही कॉलबैक इनवोकेशन ज़रूरी है।

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

reCAPTCHA callback क्या है?

reCAPTCHA कॉलबैक वह फ़ंक्शन है जिसका उपयोग पेज किसी CAPTCHA इवेंट पर प्रतिक्रिया देने के लिए करता है, जैसे कि सफल रिस्पॉन्स टोकन मिलना।

Google के reCAPTCHA v2 display reference में सक्सेस कॉलबैक के लिए HTML एट्रिब्यूट और रेंडरिंग ऑप्शन दोनों डाक्यूमेंटेड हैं। पेज एक्सपायरी या एरर के लिए भी हैंडलर डिफ़ाइन कर सकता है। ये हैंडलर अलग‑अलग उद्देश्य पूरा करते हैं और इन्हें सफल‑परिणाम वाले पाथ से ग़लत तरीके से न मिलाएँ।

कॉलबैक एक टोकन स्टोर कर सकता है, फ़ॉर्म स्टेट अपडेट कर सकता है, किसी कंट्रोल को इनेबल कर सकता है या कोई एप्लिकेशन रिक्वेस्ट शुरू कर सकता है। वह क्या करता है यह एप्लिकेशन तय करती है। केवल नाम से उसका व्यवहार तय नहीं होता, और न ही यह ज़रूरी है कि हर साइट का फ़ंक्शन onSuccess ही हो।

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

कॉलबैक देखने से पहले, मौजूदा विजेट की पहचान करें

हैंडलर खोजने से पहले पेज, फ़ॉर्म, CAPTCHA वर्ज़न और वर्कफ़्लो स्टेप की पहचान करें।

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

डेवलपमेंट और प्रोडक्शन एनवायरमेंट को अलग‑अलग पहचानने योग्य रखें। लोकल बिल्ड में फ़ंक्शन के नाम पढ़ने योग्य हो सकते हैं जबकि प्रोडक्शन बंडल उन्हें बदल देता है। कॉन्फ़िगर किया गया पब्लिक साइटकी भी अलग हो सकता है। किसी दूसरे एनवायरमेंट से कॉलबैक पाथ ट्रांसफर करने के बजाय, पेज के वास्तविक सोर्स और रनटाइम बिहेवियर का उपयोग करें।

CapSolver parameter detector चैलेंज पैरामीटर की पहचान में मदद कर सकता है। यह एप्लिकेशन निरीक्षण का पूरक है; यह यह समझने की ज़रूरत को रिप्लेस नहीं करता कि कौन‑सा हैंडलर रिज़ल्ट कंज़्यूम करता है। अगर आपको यह नहीं पता कि कौन‑सा CAPTCHA परिवार मौजूद है, तो पहले CAPTCHA identification guide का उपयोग करें।

केवल इस आधार पर वर्ज़न का अनुमान न लगाएँ कि इमेज पज़ल दिखा या नहीं। इम्प्लीमेंटेशन और डाक्यूमेंटेड API उपयोग, इंटरेक्शन के एक स्क्रीनशॉट से ज़्यादा ठोस सबूत देते हैं।

विधि 1: विजेट मार्कअप में data-callback देखें

जब इंटीग्रेशन अपना हैंडलर HTML में डिक्लेयर करता है तो प्रासंगिक विजेट मार्कअप में data-callback को खोजें।

पेज के डेवलपर टूल्स खोलें और उस फ़ॉर्म या कंपोनेंट को इन्स्पेक्ट करें जिसमें चैलेंज मौजूद है। Elements पैनल में ठीक इसी एट्रिब्यूट नाम को खोजें। अगर यह मौजूद है, तो नामित हैंडलर और जिस विजेट से यह जुड़ा है, दोनों को नोट कर लें।

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

सक्सेस, एक्सपायरी और एरर कॉलबैक में फ़र्क करें

सफल परिणाम वाले पाथ को समझने के लिए सक्सेस हैंडलर का उपयोग करें, और एक्सपायरी व एरर हैंडलर को अलग‑अलग ब्रांच के रूप में देखें।

Google के invisible reCAPTCHA reference में ये अलग‑अलग कॉलबैक ऑप्शन डाक्यूमेंटेड हैं। एक्सपायर्ड‑रिस्पॉन्स हैंडलर स्टेट को क्लियर कर सकता है या दोबारा वेरिफिकेशन के लिए कह सकता है। एरर हैंडलर कनेक्टिविटी मैसेज दिखा सकता है। इन्हें सक्सेसफुल‑रिज़ल्ट हैंडलर के रिप्लेसमेंट के रूप में न लें।

अगर data-callback मौजूद नहीं है, तो यह निष्कर्ष न निकालें कि इंटीग्रेशन टूटा हुआ है। एप्लिकेशन जावास्क्रिप्ट में कॉलबैक रजिस्टर कर सकती है या कोई और डाक्यूमेंटेड रिज़ल्ट फ़्लो इस्तेमाल कर सकती है। पेज में मनमाने ढंग से कोई एट्रिब्यूट जोड़ने के बजाय रेंडरिंग कोड पर जाएँ।

विधि 2: grecaptcha.render को पास किए गए callback को जाँचें

जब विजेट को जावास्क्रिप्ट के ज़रिए एक्सप्लिसिट रूप से बनाया जाता है, तो grecaptcha.render में पास किए गए कॉन्फ़िगरेशन को जाँचें।

लोडेड एप्लिकेशन सोर्स में रेंडरिंग कॉल को खोजें और उसके ऑप्शन रिव्यू करें। callback एंट्री किसी नामित फ़ंक्शन की ओर इशारा कर सकती है या इनलाइन फ़ंक्शन हो सकती है। उस रेफ़रेंस को एप्लिकेशन कोड में फ़ॉलो करें और देखें कि वह किस फ़ॉर्म या कंपोनेंट को अपडेट करता है।

रेंडरिंग कॉल से यह साबित नहीं होता कि पेज reCAPTCHA v3 का उपयोग कर रहा है। वर्ज़न की पहचान के लिए पूरी इंटीग्रेशन कॉन्टेक्स्ट को देखना चाहिए। कॉपी की गई किसी कोड स्निपेट पर लगी वर्ज़न लेबल से अकेले यह तय नहीं किया जा सकता कि कौन‑सा सॉल्वर टास्क या रिज़ल्ट‑हैंडलिंग मेथड चुनना है।

लोड ऑर्डर और विजेट इंस्टेंस जाँचें

पक्का कर लें कि जो कोड आपने पाया है, वह वास्तव में मौजूदा विजेट के लिए चल रहा है।

कोई इनिशियलाइज़ेशन फ़ंक्शन डिफ़ाइन तो हो सकता है पर कभी कॉल न हो, या डिपेंडेंसी उपलब्ध होने से पहले चल जाए। कोई दूसरा कंपोनेंट बाद में विजेट को बदल सकता है। सोर्स में दिख रही हर रेंडरिंग कॉल को मौजूदा विजेट से जोड़ने की बजाय, ब्रेकपॉइंट का उपयोग करके सक्रिय पाथ को ऑब्ज़र्व करें।

जब कई विजेट मौजूद हों, तो उनकी पहचान और एप्लिकेशन स्टेट अलग‑अलग रखें। कोई हैंडलर जो एक कंपोनेंट को अपडेट करता है, उसे बिना बताए दूसरे के लिए आए रिज़ल्ट को कंज़्यूम नहीं करना चाहिए। यह विशेष रूप से तब उपयोगी है जब कोई फ़ॉर्म अकेला काम करता है, लेकिन उसी एप्लिकेशन के भीतर नेविगेशन के बाद फ़ेल होने लगता है।

अपना CapSolver बोनस कोड रिडीम करें

अपने ऑटोमेशन बजट को तुरंत बढ़ाएँ!
CapSolver अकाउंट टॉप‑अप करते समय बोनस कोड CAP26 का उपयोग करें और हर रिचार्ज पर अतिरिक्त 5% बोनस पाएँ — बिना किसी लिमिट के।
अभी इसे अपने CapSolver Dashboard में रिडीम करें।

विधि 3: reCAPTCHA v3 में रिज़ल्ट हैंडलर को फ़ॉलो करें

reCAPTCHA v3 के लिए, देखें कि एप्लिकेशन grecaptcha.execute द्वारा रिटर्न किए गए रिज़ल्ट को कैसे हैंडल करती है।

Google के reCAPTCHA v3 guide में एक प्रोग्रामेटिक फ़्लो दिखाया गया है, जिसमें grecaptcha.execute एक टोकन को प्रॉमिस हैंडलर को लौटाता है। अगली एप्लिकेशन‑लेवल कार्रवाई उसी हैंडलर के भीतर होती है। विजेट मार्कअप से कॉपी करने लायक कोई ग्लोबल फ़ंक्शन नाम मौजूद न भी हो सकता है।

कोड को execute कॉल से लेकर हैंडलर और फिर बैकएंड रिक्वेस्ट तक फ़ॉलो करें। एप्लिकेशन द्वारा उपयोग किए गए action कॉन्टेक्स्ट को नोट करें और कन्फर्म करें कि लौटा हुआ वैल्यू सही रिक्वेस्ट तक पहुँचती है। केवल इस वजह से किसी दूसरे action के हैंडलर को सब्स्टीट्यूट न करें कि उसे भी टोकन मिलता है।

Anonymous फ़ंक्शन भी एप्लिकेशन हैंडलर ही होते हैं

एक अनाम (anonymous) फ़ंक्शन, बिना किसी स्थिर ग्लोबल नाम के भी, नामित कॉलबैक जितना ही काम कर सकता है।

सोर्स में उसके पंजीकरण (registration) पॉइंट को खोजें और डिबगर के साथ उसे ऑब्ज़र्व करें। अपने स्वामित्व वाले कोडबेस में आमतौर पर सबसे साफ़ समाधान यही है कि एप्लिकेशन की एक्सप्लिसिट हैंडलर इंटरफ़ेस को देखें या टेस्ट करें। केवल किसी ट्यूटोरियल से मेल खाने के लिए इंटरनल फ़ंक्शन का नाम बदलना या उन्हें एक्सपोज़ करना इम्प्लीमेंटेशन के साथ अनावश्यक कप्लिंग बना सकता है।

महत्त्वपूर्ण सवाल यह है कि टोकन कहाँ जाता है और उसके बाद कौन‑कौन से स्टेट चेंज होते हैं। फ़ंक्शन का नाम सुविधाजनक है या नहीं, यह उस डेटा फ़्लो से द्वितीयक है।

विधि 4: जब नाम स्पष्ट न हों, तो डिबगिंग का उपयोग करें

जब एट्रिब्यूट और सोर्स सर्च से सक्रिय हैंडलर साफ़ न दिखे, तो ब्रेकपॉइंट और कॉल स्टैक का उपयोग करें।

Chrome के ब्रेकपॉइंट डाक्यूमेंटेशन में line‑of‑code, फ़ंक्शन और exception ब्रेकपॉइंट का वर्णन है। अपनी एप्लिकेशन के हैंडलर में एक ब्रेकपॉइंट लगाने से आप आर्ग्युमेंट, आसपास की स्टेट और अगली कॉल को देख सकते हैं। exception ब्रेकपॉइंट दिखा सकते हैं कि कोई हैंडलर तो चला, लेकिन फ़ॉर्म अपडेट होने से पहले ही रुक गया।

बंडल्ड एप्लिकेशन के लिए, उपलब्ध सोर्स मैप्स और वह सोर्स उपयोग करें जिस पर आपका नियंत्रण है। पढ़ने योग्य सोर्स लोकेशन, इम्प्लीमेंटेशन‑स्पेसिफ़िक रनटाइम ऑब्जेक्ट के पाथ से ज़्यादा आसान मेंटेन होती है। अगर कोई फ़ंक्शन मौजूदा स्कोप से बाहर है, तो यह देखिए कि वह कहाँ रजिस्टर किया गया है, न कि यह मानिए कि कंसोल उसे नाम से कॉल कर सकेगा।

ऑटोमैटिक internal‑object सर्च पर निर्भर क्यों न हों?

किसी internal‑object सर्च को डाक्यूमेंटेड इंटीग्रेशन कॉन्ट्रैक्ट का विकल्प नहीं मानना चाहिए।

पहले के कुछ डिबगिंग उदाहरणों में ___grecaptcha_cfg.clients की जाँच करना और नेस्टेड ऑब्जेक्ट्स से पाथ बनाना दिखाया गया होगा। वे पाथ सिर्फ़ एक रनटाइम लेआउट के ऑब्ज़र्वेशन हैं। यहाँ संदर्भित पब्लिक इंटीग्रेशन रेफ़रेंस यह वादा नहीं करते कि लेआउट, न्यूमेरिक IDs या नेस्टेड प्रॉपर्टी नाम वर्ज़न और बिल्ड्स के बीच स्थिर रहेंगे।

समर्थित विजेट कॉन्फ़िगरेशन और एप्लिकेशन सोर्स को मुख्य सबूत के रूप में उपयोग करें। CAPTCHA वर्ज़न को किसी न्यूमेरिक internal client ID से न निकालें और न ही किसी नेस्टेड कॉलबैक पाथ को लंबे समय तक चलने वाले इंटीग्रेशन में कॉपी करें। इसी कारण यह गाइड किसी ऑटोमैटिक ट्रैवर्सल स्क्रिप्ट को भरोसेमंद प्रोडक्शन समाधान के रूप में पेश नहीं करता।

कॉलबैक चलने के बाद क्या होता है, यह जाँचें

पक्का करें कि एप्लिकेशन टोकन हैंडल करने के बाद इरादे वाली रिक्वेस्ट भेजती है और खुद का सफल परिणाम प्राप्त करती है।

स्वामित्व वाले टेस्ट फ़ॉर्म के लिए, ब्राउज़र‑साइड स्टेट ट्रांज़िशन और बैकएंड रिस्पॉन्स दोनों को इन्स्पेक्ट करें। हो सकता है हैंडलर सफलतापूर्वक चल जाए, लेकिन कोई दूसरी वेलिडेशन रूल सबमिशन को रोक दे। उलटा भी हो सकता है: रिक्वेस्ट भेज दी जाए लेकिन वेरिफिकेशन के दौरान रिजेक्ट हो जाए। इन दोनों के लिए अलग‑अलग समाधान चाहिए।

CapSolver reCAPTCHA v2 task reference सॉल्वर रिस्पॉन्स का वर्णन करता है, जबकि एप्लिकेशन का कोड यह तय करता है कि वह रिस्पॉन्स उसकी वर्कफ़्लो में कैसे प्रवेश करता है। यह न मानें कि किसी hidden फ़ील्ड को वैल्यू असाइन कर देने से हमेशा फ़्रेमवर्क स्टेट अपडेट या फ़ॉर्म सबमिशन ट्रिगर हो जाएगा। वास्तविक एप्लिकेशन कॉन्ट्रैक्ट को फ़ॉलो करें।

Google के server‑side verification reference में समझाया गया है कि टोकन सिंगल‑यूज़ होते हैं और दो मिनट के लिए वैध रहते हैं। लंबा डिबगिंग पॉज़ बाद की सबमिशन के रिज़ल्ट को बदल सकता है। ज़रूरत पड़ने पर अनुमत फ़्लो के ज़रिए नया रिस्पॉन्स कलेक्ट करें, और किसी एक्सपायर्ड टोकन का उपयोग असंबंधित फ़ॉर्म बिहेवियर डायग्नोज़ करने के लिए न करें।

डायग्नोस्टिक आउटपुट सीमित रखें

हैंडलर का लोकेशन, विजेट एसोसिएशन, फ़ंक्शन चला या नहीं, और प्रोग्रेस किस स्टेज पर रुकी — इन्हें रिकॉर्ड करें।

पूरे टोकन, API keys, cookies या असंबंधित फ़ॉर्म वैल्यू को पब्लिक रिपोर्ट्स में पेस्ट करने से बचें। अधिकतर मामलों में “हैंडलर को वैल्यू मिली, सबमिशन हुआ, बैकएंड ने रिस्पॉन्स रिजेक्ट कर दिया” जैसा बयान काफ़ी उपयोगी होता है, बिना वैल्यू को उजागर किए। अगर सपोर्ट को अतिरिक्त सबूत चाहिए, तो उसे उचित चैनल के माध्यम से दें।

रिज़ल्ट से लेकर completion तक एप्लिकेशन कॉन्ट्रैक्ट को फ़ॉलो करें

सबसे उपयोगी कॉलबैक एनालिसिस वह है जो मौजूदा विजेट को उसके रजिस्टर किए गए हैंडलर, बैकएंड रिक्वेस्ट और अंतिम एप्लिकेशन रिज़ल्ट से जोड़ता है।

data-callback से शुरू करें, फिर एक्सप्लिसिट रेंडरिंग और v3 रिज़ल्ट हैंडलर देखें, और जहाँ सोर्स पाथ स्पष्ट न हो वहाँ डिबगिंग का उपयोग करें। CapSolver एक समर्थित solving स्टेप देता है; सही एप्लिकेशन‑साइड हैंडलिंग यह तय करती है कि वह रिज़ल्ट आपके अधिकृत वर्कफ़्लो में कैसे भाग लेगा।

CapSolver के साथ भरोसेमंद ऑटोमेशन वर्कफ़्लो बनाएँ

मौजूदा चैलेंज पैरामीटर और एप्लिकेशन के रिज़ल्ट‑हैंडलिंग पाथ की पुष्टि करने के बाद ही solve दोहराएँ या वर्कफ़्लो को बढ़ाएँ।

FAQ

प्र: क्या हर reCAPTCHA इंटीग्रेशन में नामित callback होता है?

नहीं। हैंडलर जावास्क्रिप्ट में रजिस्टर हो सकता है या किसी प्रॉमिस से जुड़ा हो सकता है, और वह anonymous भी हो सकता है। यह मान लेने के बजाय कि कोई ग्लोबल फ़ंक्शन ज़रूर मौजूद होगा, वास्तविक इंटीग्रेशन को इन्स्पेक्ट करें।

प्र: मुझे reCAPTCHA callback सबसे पहले कहाँ ढूँढना चाहिए?

मौजूदा प्रासंगिक विजेट के data-callback एट्रिब्यूट से शुरू करें, फिर grecaptcha.render को पास किए गए ऑप्शन और एप्लिकेशन के रिज़ल्ट‑हैंडलिंग कोड को जाँचें।

प्र: क्या grecaptcha.render का मतलब है कि पेज v3 का उपयोग कर रहा है?

नहीं। केवल मेथड नाम से वर्ज़न की पहचान नहीं होती। सॉल्वर फ़ील्ड या रिस्पॉन्स‑हैंडलिंग मेथड चुनने से पहले पूरी कॉन्फ़िगर की हुई इंटीग्रेशन की समीक्षा करें।

प्र: क्या कॉपी किया हुआ ___grecaptcha_cfg पाथ भरोसेमंद है?

इसे किसी एक रनटाइम ऑब्ज़र्वेशन के रूप में लें, न कि स्थिर पब्लिक API के रूप में। मेंटेन किए जाने वाले इंटीग्रेशन के लिए डाक्यूमेंटेड कॉन्फ़िगरेशन और एप्लिकेशन सोर्स को प्राथमिकता दें।

प्र: कॉलबैक चल जाता है, फिर भी फ़ॉर्म फेल क्यों हो जाता है?

कॉलबैक सिर्फ़ एक स्टेज है। फ़ॉर्म वेलिडेशन, रिज़ल्ट ले जाने वाली रिक्वेस्ट, सर्वर‑साइड वेरिफिकेशन, और टोकन उसके उपयोग के समय तक वैध था या नहीं — इन सब की जाँच करें।