ERROR_WRONG_USER_KEY और 3 request errors कैसे ठीक करें

error_wrong_user_key का मतलब है कि आपकी API key कभी आपके कोड से बाहर निकली ही नहीं। पूरा निदान बस इतना ही है, और इसे शुरू में ही कह देना ज़रूरी है क्योंकि लगभग हर कोई इसे “मेरी key गलत है” समझ लेता है और नई key चिपकाने लगता है। गलत key के लिए CapSkip के पास अलग code है। error_wrong_user_key, और इसके साथ बैठे तीन code, तब लौट आते हैं जब सॉल्वर ने कैप्चा को देखा तक नहीं होता: ये आपके भेजे गए HTTP request के ढाँचे का ब्योरा देते हैं, उस challenge का नहीं जिसके बारे में वह request थी।

चार codes, और वह code जिसके साथ इनका भ्रम होता है

ये submit endpoint या poll endpoint से सादे text के रूप में लौटते हैं, सामान्य OK जवाब की जगह पर। इनमें से हर एक निश्चित है। एक जैसी request दोबारा भेजने पर जवाब भी एक जैसा ही आता है, इसलिए इनमें से किसी के इर्द-गिर्द retry loop लगाना समय की बरबादी है। नीचे की दूसरी पंक्ति वह सहोदर code है जो इन चारों में शामिल नहीं है, क्योंकि इन दोनों में फ़र्क़ करना ही असल काम है।

पूरी सूची, जिसमें image upload वाले codes और reCAPTCHA से जुड़े codes भी हैं, यहाँ है: CapSkip API डॉक्यूमेंटेशन.

ERROR_WRONG_USER_KEY: key गलत नहीं, गायब है

गायब होना और अमान्य होना दो अलग बग हैं जिनके इलाज भी अलग हैं, और CapSkip इन्हें जानबूझकर अलग रखता है। अगर कोई key server तक पहुँची और पहचानी नहीं गई, तो आपको error_key_does_not_exist मिलता है, जिस पर यहाँ लिखा गया है: उस code की गाइड। अगर इसकी जगह आपको error_wrong_user_key मिलता है, तो पहचानने लायक़ कुछ पहुँचा ही नहीं, इसलिए मान को देखना छोड़ें और यह देखना शुरू करें कि वह भेजा भी गया था या नहीं।

# No key parameter at all. This is what produces it.
curl -X POST \
  -d "method=userrecaptcha" \
  -d "googlekey=YOUR_SITEKEY" \
  -d "pageurl=https://example.com/page-with-recaptcha" \
  http://127.0.0.1:8080/in.php

ERROR_WRONG_USER_KEY

इसे चार चीज़ें पैदा करती हैं, मोटे तौर पर उसी क्रम में जिस क्रम में ये आम हैं:

• कोई environment variable जो वहाँ सेट ही नहीं है जहाँ कोड चलता है। इसका क्लासिक रूप यह है कि shell के पास वह मौजूद है और service के पास नहीं। मान खाली string के रूप में पढ़ा जाता है और client key भेजता है जिसके आगे कुछ होता ही नहीं।
• ऐसी config file से पढ़ी गई key जो कोड के साथ deploy ही नहीं हुई।
• हाथ से बनाया गया कोई client जो key तभी जोड़ता है जब कोई variable truthy हो, इसलिए खाली string चुपचाप उस पैरामीटर को गिरा देती है।
• ऐसा client जो पैरामीटर वहाँ रख देता है जहाँ से request उन्हें ले ही नहीं जाएगी, जैसे form fields पढ़ने वाले endpoint पर JSON body।

call से पहले मान नहीं, मान की लंबाई print करें। शून्य लंबाई आपको वही बता देती है जो चाहिए और किसी credential को log file में नहीं डालती।

यह सिर्फ़ server पर ही क्यों शुरू होता है

यहीं वे लोग उलझते हैं जो महीनों से वही कोड चला रहे हैं। CapSkip key तभी माँगता है जब ऐप में API Key Validation चालू हो। ताज़े लोकल install पर यह बंद रहती है, इसलिए बिना किसी key वाली request भी स्वीकार हो जाती है और कोई कभी शिकायत नहीं करता। हो सकता है आपका client जिस दिन से लिखा गया, उसी दिन से खाली key भेज रहा हो।

फिर आप सॉल्वर को ऐसी मशीन पर ले जाते हैं जो आपकी मेज़ पर नहीं है। CapSkip में दो connection modes हैं: Local, 127.0.0.1 से bind होता है और सिर्फ़ उसी डिवाइस को जवाब देता है, जबकि Server, आपके network या public IP से bind होता है ताकि कोई दूसरी मशीन, कोई VPS या कोई hosted worker उस तक API के ज़रिए पहुँच सके। एक static public IP उस पते को स्थिर रखता है। दोनों का ब्योरा यहाँ है: कनेक्शन सेटिंग्स। जब आप यह बदलाव करें, तभी key validation चालू करना सही क़दम है, और यही वह पल भी होता है जब आपके कोड में छिपा हर key bug एक साथ सामने आ जाता है। दोनों ही सूरत में यह अब भी आपका अपना hardware है और अब भी बिना मीटर के चलता है, इसलिए यह सिर्फ़ एक configuration बदलाव है, आपके ख़र्च में बदलाव नहीं।

अगर आप कई workers को keys बाँट रहे हैं, तो हर एक को उसकी अपनी key दें ताकि किसी एक key को बाक़ियों को छुए बिना रद्द किया जा सके। इसका यह पहलू यहाँ कवर किया गया है: कैप्चा API keys जारी करने की गाइड.

ERROR_WRONG_ID_FORMAT: शायद आपने पूरा जवाब ही भेज दिया

इसकी एक ही प्रमुख वजह है और एक बार पता चल जाए तो पकड़ना आसान है। submit endpoint सिर्फ़ एक संख्या से जवाब नहीं देता। वह OK और id को एक pipe से अलग करके लौटाता है, और जो client उस पूरी string को सीधे poll request में डाल देता है, वह ऐसी id भेजता है जो संख्या है ही नहीं।

# What in.php actually returns:
OK|212

# Wrong. The whole reply went into id.
curl "http://127.0.0.1:8080/res.php?key=YOUR_API_KEY&action=get&id=OK|212"
ERROR_WRONG_ID_FORMAT

# Right. Split on the pipe and send the number.
curl "http://127.0.0.1:8080/res.php?key=YOUR_API_KEY&action=get&id=212"

JSON माँग लें तो parsing कम नाज़ुक हो जाती है, क्योंकि तब id किसी delimited string के आधे हिस्से के बजाय एक field के रूप में आती है। दोनों ही सूरत में split करने से पहले prefix जाँच लें, क्योंकि error code में कोई pipe नहीं होता और आँख मूँदकर split करने पर वही error code आपको id बनकर वापस मिल जाता है।

# A hand rolled client has to do this itself. The SDK does not,
# which is most of why it is worth using.
reply = httpx.post(IN_URL, data=payload).text     # "OK|212"

if not reply.startswith("OK|"):
    raise RuntimeError(reply)                     # it is an error code

captcha_id = reply.split("|", 1)[1]               # "212"

raw request और poll चक्र का एक हल किया हुआ उदाहरण, उसी delimiter handling के साथ, यहाँ है: curl से कैप्चा हल करने का वॉकथ्रू.

ERROR_WRONG_METHOD: गलत verb, या गलत शब्द

दो अलग-अलग गलतियाँ यही एक code साझा करती हैं, इसीलिए यह धुँधला लगता है। पहली है HTTP verb: जिस endpoint को आपने GET से call किया, उस पर form body में भेजे गए पैरामीटर कहीं नहीं पहुँचते। दूसरी है ख़ुद method पैरामीटर, जो उस प्रकार के लिए CapSkip के पहचाने हुए मानों में से एक होना चाहिए जिसे आप हल कर रहे हैं: image के लिए post या base64, दोनों में से किसी भी version के reCAPTCHA के लिए userrecaptcha, Cloudflare के लिए turnstile, GeeTest v3 के लिए geetest।

ज़्यादातर मामले दो हिज्जों से बनते हैं: reCAPTCHA endpoint को sitekey भेजना, जबकि वह googlekey चाहता है, और userrecaptcha की जगह recaptcha या userecaptcha भेजना। यही code poll वाली तरफ़ भी लागू होता है, जहाँ action को अक्षरशः get होना चाहिए।

ERROR_BAD_PARAMETERS: प्रकार और fields आपस में मेल नहीं खाते

method तो समझ लिया गया, पर उसके लिए ज़रूरी कोई चीज़ गायब थी या ख़राब थी। यह हर प्रकार के हिसाब से अलग होता है, इसलिए काम का सवाल हमेशा यही है कि CapSkip के हिसाब से आपने कौन सा प्रकार माँगा।

• reCAPTCHA को googlekey और pageurl दोनों चाहिए, और pageurl उस पेज का पूरा URL होना चाहिए जिस पर widget लोड होता है, scheme समेत।
• reCAPTCHA v3 के लिए version को v3 करना ज़रूरी है। उसके साथ invisible भेजना v3 की request पर v2 का field डालना है।
• Turnstile के challenge pages को sitekey के अलावा data और pagedata भी चाहिए। Widget mode को इनमें से कोई नहीं चाहिए।
• GeeTest को gt और challenge साथ-साथ चाहिए, और challenge करीब एक मिनट में expire हो जाता है, इसलिए बासी challenge बाद में नहीं, यहीं फेल होता है।
• Image कैप्चा को multipart upload के लिए file चाहिए या base64 के लिए body, और कभी दोनों नहीं।

जो payload आप भेजने वाले हैं उसे key छिपाकर log करें, और उसे उस प्रकार की parameter तालिका से मिलाकर पढ़ें। दस में नौ बार जवाब उसी एक लाइन में दिख जाता है।

खाली response इनमें से एक नहीं है

जो poll कुछ भी नहीं लौटाता वह अलग स्थिति है, और उसका नाम लेना ज़रूरी है क्योंकि खाली जवाब को ख़राब id समझ लिया जाता है। खाली body का मतलब है कि नतीजा पहले ही ले लिया गया, या वह id मौजूद ही नहीं है। CapSkip नतीजा एक ही बार पढ़ने देता है। जो retry loop सफल होकर भी दोबारा घूम जाता है क्योंकि कोड में break लगाना छूट गया, वह दूसरी बार खाली string पढ़ता है और ठीक से हल हुए कैप्चा पर विफलता की सूचना दे देता है।

नतीजा पहली ही बार मिलते ही सहेज लें। और खाली response को CAPCHA_NOT_READY से न उलझाएँ, जो विफलता नहीं बल्कि polling की एक सामान्य स्थिति है, और जिसका ब्योरा यहाँ है: उस response की गाइड.

इन्हें SDK से पढ़ना

चारों codes में से हर एक ApiException के रूप में आता है, जिसमें code ही संदेश होता है। सबसे पहले यही exception जाँचनी चाहिए, क्योंकि इसका मतलब है कि CapSkip ने आपकी बात समझी और मना कर दिया, और यह CapSkip तक बिल्कुल भी न पहुँच पाने से अलग किस्म की समस्या है।

# pip install capskip
from capskip import CapSkip, ApiException, NetworkException

solver = CapSkip(host="127.0.0.1", port=8080, apiKey=API_KEY)

try:
    token = solver.recaptcha(sitekey=SITEKEY, url=PAGE_URL)["code"]
except ApiException as err:
    # CapSkip answered and rejected the request. Do not retry.
    print("Rejected:", err)
except NetworkException as err:
    # CapSkip did not answer. Wrong host, wrong port, or not running.
    print("Unreachable:", err)

यहाँ ValidationException के बारे में जानना भी काम का है, क्योंकि यह कुछ भी भेजे जाने से पहले ही चल जाती है। SDK ऐसे पैरामीटर अस्वीकार कर देता है जो आपके माँगे गए प्रकार के लिए गलत हैं, इसलिए जो गलती raw HTTP पर ERROR_BAD_PARAMETERS बनकर लौटती, वह उसकी जगह लोकल रूप से ही पकड़ी जाती है, और संदेश में उस argument का नाम भी होता है। SDK में कुल चार exception प्रकार हैं: ApiException, NetworkException, TimeoutException और ValidationException। अगर आप इन्हें एक ही जगह संभालना चाहें, तो इनमें से हर एक CapSkipError नाम के एक base से निकला है। यही चारों Node.js, PHP और C# clients में भी हैं, जिनकी सूची यहाँ है: CAPTCHA solving SDK पेज.

FAQ

संक्षेप में

ये चारों codes आपकी request के बारे में हैं, कैप्चा के बारे में नहीं। error_wrong_user_key का मतलब है कि key पैरामीटर में कुछ पहुँचा ही नहीं, और यह गलत मान नहीं बल्कि configuration की समस्या है। ERROR_WRONG_ID_FORMAT का मतलब लगभग हमेशा यही होता है कि pipe से अलग किया गया जवाब पूरा का पूरा भीतर चला गया। ERROR_WRONG_METHOD का मतलब है गलत verb या गलत हिज्जे, और ERROR_BAD_PARAMETERS का मतलब है ऐसा field जो आपके माँगे गए प्रकार का है ही नहीं। इनमें से किसी को भी दोबारा आज़माना काम का नहीं।

इनमें से हर एक का फ़ैसला कर देने वाली parameter तालिकाएँ यहाँ हैं: API documentation पेज। जो Python client इनमें गलती की ज़्यादातर गुंजाइश ही ख़त्म कर देता है, वह यहाँ है: Python कैप्चा सॉल्वर पेज.

debugging करते समय याद रखने लायक़ बात: CapSkip एक कैप्चा बायपास टूल है जो आपके अपने hardware पर चलता है, इसलिए समझने की कोशिश में सौ बार भेजी गई कोई ख़राब request आपको समय के अलावा कुछ नहीं पड़ती।