Patchright Automation में CAPTCHA सॉल्वर कैसे जोड़ें

सारांश

• Patchright एक Chromium ब्राउज़र को नियंत्रित करता है; ऐसी CAPTCHA जिसके लिए प्रतिक्रिया ज़रूरी हो, उसके लिए अभी भी अलग सॉल्विंग स्टेप की आवश्यकता रहती है।
• reCAPTCHA की डिटेक्शन पेज के मुख्य JavaScript environment की state पर निर्भर कर सकती है, जबकि Patchright डिफ़ॉल्ट रूप से स्क्रिप्ट्स को एक isolated environment में चलाता है।
• एक छोटा‑सा पेज एडेप्टर आधिकारिक CapSolver Core SDK को वही Patchright पेज inspect करने देता है, बिना दूसरा ब्राउज़र खोलने के।
• पहले लोकल टेस्ट विजेट से शुरू करें, फिर पेड़ solving और एप्लिकेशन की प्रतिक्रिया को अलग‑अलग वैलिडेट करें, उसके बाद ही बड़े workflow में इंटीग्रेशन का इस्तेमाल करें।

कोई Patchright स्क्रिप्ट सही तरह नेविगेट कर सकती है, फ़ॉर्म ढूंढ सकती है, और फिर reCAPTCHA विजेट पर आकर रुक सकती है। सिर्फ़ ब्राउज़र लाइब्रेरी बदल देने से वह response नहीं मिलता जिसकी विजेट और एप्लिकेशन को ज़रूरत है। ऐसे में आपको CAPTCHA solver की ज़रूरत होती है, और साथ ही यह भी जाँचना ज़रूरी है कि एप्लिकेशन ने परिणाम स्वीकार किया या नहीं।

यह Patchright CAPTCHA solver ट्यूटोरियल Python ब्राउज़र सेशन को आधिकारिक Core SDK के ज़रिये CapSolver से जोड़ता है। अहम बात है पेज का JavaScript environment: दिखने वाले DOM को पढ़ना और reCAPTCHA की page‑owned configuration को पढ़ना अलग‑अलग ऑपरेशन हैं। नीचे दिया गया उदाहरण इस फ़र्क को सँभालता है, एक ही पेज खुला रखता है, और लोकल डेवलपमेंट फ़िक्स्चर पर डिटेक्शन की पुष्टि करता है। इस तरीके का उपयोग उन्हीं पेजों पर करें जो आपके अपने हों या जिनको automate करने की आपको अनुमति हो।

Patchright क्या है और CAPTCHA solver कब मदद करता है

Patchright, Playwright का community‑maintained derivative है, जिसका Python automation इंटरफ़ेस काफ़ी हद तक समान है। आधिकारिक Python रिपॉज़िटरी इसके Chromium सपोर्ट और Playwright की जगह इसे import करने के तरीक़े को दस्तावेज़ करती है। Patchright Firefox और WebKit को सपोर्ट नहीं करता।

डेवलपर्स Patchright का उपयोग पेजों को नियंत्रित करने, एलिमेंट्स से इंटरैक्ट करने और ब्राउज़र वर्कफ़्लो चलाने के लिए करते हैं। Solver तब उपयोगी होता है जब कोई समर्थित CAPTCHA किसी अधिकृत वर्कफ़्लो को फ़ॉर्म पूरा करने या अपेक्षित परिणाम तक पहुँचने से रोक देता है। अगर आपका पेज पहले से ही सुलभ है, तो पेड़ solving रिक्वेस्ट करने की ज़रूरत नहीं है।

इस इंटीग्रेशन की तीन अलग‑अलग ज़िम्मेदारियाँ हैं। Patchright नेविगेशन और पेज की लाइफ़टाइम को नियंत्रित करता है। Solver समर्थित challenge इनपुट्स पढ़कर solution माँगता है। आपका एप्लिकेशन वर्कफ़्लो तय करता है कि फ़ॉर्म या अगला पेज वास्तव में सफल हुआ या नहीं। CAPTCHA glossary इस अलगाव के पीछे के verification मैकेनिज़्म को समझाता है।

अपनी एप्लिकेशन के रूटीन टेस्ट के लिए CAPTCHA वेंडर की development settings को तरजीह दें। पेड़ solver इंटीग्रेशन चेक, इस बात की जाँच से अलग काम है कि आपका सामान्य फ़ॉर्म validation सही चल रहा है या नहीं।

reCAPTCHA डिटेक्शन को सही page context की ज़रूरत क्यों होती है

reCAPTCHA डिटेक्शन को उस configuration की ज़रूरत हो सकती है जो विजेट पेज के main JavaScript environment में बनाता है। Patchright के documented evaluate() विकल्प isolated_context की डिफ़ॉल्ट वैल्यू True है; इस वजह से पेज‑owned JavaScript global आम evaluation में ग़ायब हो सकते हैं, भले ही विजेट पेज पर दिख रहा हो।

इस गाइड के लिए इस्तेमाल किए गए नियंत्रित उदाहरण में, डिफ़ॉल्ट evaluation window.___grecaptcha_cfg को नहीं देख पा रहा था, जबकि isolated_context=False के साथ evaluation इसे देख पाता था। इस reCAPTCHA पाथ के लिए SDK को उस page state तक पहुँच की ज़रूरत है। इसीलिए timeout या खाली detection रिज़ल्ट आने पर, site key बदलने या बार‑बार solving रिक्वेस्ट सबमिट करने से पहले context की जाँच करनी चाहिए।

नीचे दिया गया एडेप्टर SDK की evaluations को पेज के main environment तक फ़ॉरवर्ड करता है। यह Patchright की इंस्टॉल की गई फ़ाइलों में कोई बदलाव नहीं करता और न ही हर ब्राउज़र ऑपरेशन के लिए environment बदलता है। नेविगेशन और साधारण locators raw_page पर ही रहते हैं; सिर्फ़ वही page object जो SDK को दिया जाता है, इस wrapper का इस्तेमाल करता है। इसे नीचे दी गई versions के लिए tested integration example की तरह समझें, न कि किसी आधिकारिक Patchright पार्टनरशिप या सार्वभौमिक कम्पैटिबिलिटी के दावे की तरह।

पैकेज इंस्टॉल करें और prerequisites जाँचें

उदाहरण में Python 3.12, Patchright 1.64.1 और capsolver-core 0.1.1 का इस्तेमाल हुआ है। पैकेजों को isolated environment में इंस्टॉल करें और Patchright का Chromium runtime इंस्टॉल करें। setup check के लिए इन versions को pin करें ताकि किसी पैकेज upgrade से उसका behavior चुपचाप न बदल जाए।

python3 -m venv .venv
source .venv/bin/activate
python -m pip install "patchright==1.64.1" "capsolver-core==0.1.1"
python -m patchright install chromium

डिटेक्शन उदाहरण को CapSolver API key की ज़रूरत नहीं है। वास्तविक solving के लिए आपकी अपनी वैध key और पर्याप्त अकाउंट resources की ज़रूरत होगी। क्लाइंट को documented create_capsolver(api_key=...) विकल्प से configure करें और key को अपनी एप्लिकेशन की secret configuration में रखें। Core SDK guide क्लाइंट क्रिएशन, detection, solving और result फ़ील्ड्स को दस्तावेज़ करता है।

नीचे दिया गया setup check Google की public reCAPTCHA test key का उपयोग करने वाले लोकल पेज पर चलाया गया था। पेड़ solving, token fill‑back और solved token के प्रति एप्लिकेशन की स्वीकृति इस गाइड के लिए execute नहीं किए गए। इस fixture का उपयोग production success‑rate टेस्ट के रूप में न करें।

लोकल Patchright और SDK setup check चलाएँ

Setup check एक लोकल fixture खोलता है, टेस्ट विजेट के initialize होने का इंतज़ार करता है, और आधिकारिक SDK द्वारा लौटाए गए CAPTCHA parameters प्रिंट करता है। इसे patchright_sdk_check.py के रूप में सेव करें और ऊपर वाले environment में Python से चलाएँ।

लोकल URL एक browser route के ज़रिये serve होता है, इसलिए अलग web server की ज़रूरत नहीं है। विजेट स्क्रिप्ट अभी भी Google से लोड होती है और नेटवर्क ऐक्सेस की ज़रूरत होगी। Public site key, Google की reCAPTCHA testing guidance से लिया गया है; यह development key है, न कि कोई private credential।

import asyncio
import json

from capsolver_core import create_capsolver
from patchright.async_api import async_playwright

TEST_URL = "http://127.0.0.1:8765/"
HTML = """<!doctype html><html><head><title>CAPTCHA integration check</title></head>
<body><h1>Owned development page</h1>
<div class="g-recaptcha" data-sitekey="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"></div>
<script src="https://www.google.com/recaptcha/api.js" async defer></script>
</body></html>"""


class MainWorldPage:
    def __init__(self, page):
        self._page = page

    @property
    def url(self):
        return self._page.url

    async def evaluate(self, expression, arg=None):
        return await self._page.evaluate(expression, arg, isolated_context=False)

    async def wait_for_selector(self, selector, **kwargs):
        return await self._page.wait_for_selector(selector, **kwargs)


async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch(headless=True)
        try:
            raw_page = await browser.new_page()
            await raw_page.route(
                TEST_URL, lambda route: route.fulfill(content_type="text/html", body=HTML)
            )
            await raw_page.goto(TEST_URL)
            page = MainWorldPage(raw_page)
            for _ in range(60):
                ready = await page.evaluate(
                    "() => !!window.___grecaptcha_cfg && "
                    "Object.keys(window.___grecaptcha_cfg.clients || {}).length > 0"
                )
                if ready:
                    break
                await asyncio.sleep(0.5)
            else:
                raise RuntimeError("Test widget did not initialize")

            async with create_capsolver() as cap:
                infos = await cap.get_captcha_info(page)
                result = [{"type": info.type.value, "url": info.website_url,
                           "site_key": info.website_key} for info in infos]
                print(json.dumps({"captcha_parameters": result}))
                assert result and result[0]["type"] == "reCaptchaV2"
        finally:
            await browser.close()


if __name__ == "__main__":
    asyncio.run(main())

Successful run में एक item मिला जिसका type reCaptchaV2, लोकल page URL, और public test site key थी। यह परिणाम इस बात की पुष्टि करता है कि Patchright ने पेज खोला और SDK एडेप्टर के ज़रिए initialized विजेट को पढ़ सका। इसमें कोई solved token नहीं है, और यह साबित नहीं करता कि कोई production फ़ॉर्म भी इसे स्वीकार करेगा।

finally ब्लॉक में ब्राउज़र बंद किया जाता है, भले ही विजेट लोडिंग या detection विफल हो जाए। SDK क्लाइंट भी अपना asynchronous context बंद कर देता है। जब आप इस इंटीग्रेशन को किसी लंबे स्क्रिप्ट में ले जाएँ, तो इस cleanup को बनाए रखें, ख़ासकर तब जब कोई challenge exception पैदा करे।

CapSolver Bonus Code रिडीम करें

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

Detection check के बाद solving जोड़ें

Solving, active ब्राउज़र और SDK contexts के अंदर होना चाहिए, इससे पहले कि पेज बंद हो या कहीं और नेविगेट कर जाए। अपनी authorized application page पर, अपनी key के साथ SDK क्लाइंट बनाइए, मौजूदा Patchright page को ऊपर बताए अनुसार wrap कीजिए, और आधिकारिक browser‑mode कॉल का उपयोग कीजिए।

नीचे दी गई लाइन आधिकारिक SDK कॉल है, बिना किसी बदलाव के। इसे configured API key की आवश्यकता होती है; इस Patchright adapter के साथ पेड़ execution इस गाइड में टेस्ट नहीं की गई। इस कॉल को वहीं रखें जहाँ cap और wrapped page अभी भी scope में हों, न कि इसे standalone स्क्रिप्ट की तरह चलाएँ।

results = await cap.solve_on_page(page)

आगे बढ़ने से पहले लौटाए गए items inspect करें। SDK error, solution और filled फ़ील्ड्स expose करता है ताकि आप असफल प्रयास, returned solution और token fill‑back के बीच अंतर कर सकें। अगर कोई आवश्यक solution missing है या संबंधित result में error रिपोर्ट हो रही है, तो फ़ॉर्म सबमिट न करें।

reCAPTCHA v2 के लिए आधिकारिक task parameters पेज URL, site key और task type के बीच संबंध समझाते हैं। सुनिश्चित करें कि detect हुआ challenge इच्छित पेज से मेल खाता हो। किसी और environment से कॉपी की गई या पुराने page state की key सिर्फ़ सही फ़ॉर्मेट होने भर से उपयोगी इनपुट नहीं बन जाती।

आगे बढ़ने से पहले एप्लिकेशन का परिणाम कन्फ़र्म करें

एप्लिकेशन सफलता, solving और fill‑back के बाद अलग जाँच है। आपके workflow को अभी भी फ़ॉर्म सबमिट करने या किसी page‑specific callback का इंतज़ार करने की ज़रूरत हो सकती है। Google की server‑side verification guidance बताती है कि एप्लिकेशन को response validate क्यों करना चाहिए। अपनी एप्लिकेशन से कोई success signal परिभाषित करें, जैसे कोई confirmation संदेश या expected result सेक्शन, और जब वह signal न आए तो workflow रोक दें।

किसी HTTP response, token string, या filled=True को यह साबित करने के रूप में न लें कि पूरा browser task सफल हो गया। अगर पेज ने response को रिजेक्ट कर दिया, तो उपयोगी error summary संरक्षित करें और दोबारा प्रयास करने से पहले कारण देखें। CAPTCHA tokens और cookies पर गाइड solver outputs को समझने के लिए संदर्भ देता है।

खाली detection और विफल continuation की troubleshooting

Troubleshooting की शुरुआत उसी पहले स्टेप से होनी चाहिए जो विफल हुआ: page loading, widget initialization, context access, solving या एप्लिकेशन acceptance।

एक पेज और एक attempt से शुरुआत करें। तभी bounded retries जोड़ें जब आपको यह समझ आ जाए कि कौन‑सी विफलताएँ अस्थायी हैं। नेविगेशन के बाद किसी पुराने result का reuse करने से solution गलत page state से जुड़ सकता है, जबकि बिना समझे retry करने से लागत तो बढ़ेगी पर मूल समस्या हल नहीं होगी।

Patchright और SDK में होने वाले बदलावों को automation job upgrade करने से पहले साथ‑साथ टेस्ट करना चाहिए। इसका परिचित API हर Playwright एक्सटेंशन या SDK के लिए एक‑सा execution behavior गारंटी नहीं देता। छोटे detection check को compatibility test के रूप में संभालकर रखें, और production उपयोग से पहले अपने environment में अलग credentialed solve‑and‑application check चलाएँ।

इंटीग्रेशन को एप्लिकेशन check के साथ पूरा करें

एक उपयोगी Patchright इंटीग्रेशन, मौजूदा ब्राउज़र पेज, समर्थित CAPTCHA task और कोई observable एप्लिकेशन परिणाम—इन तीनों को जोड़ता है। पहले page‑context access verify करें, फिर अपनी credentials के साथ पेड़ solving validate करें, और आख़िर में देखें कि इच्छित ब्राउज़र action पूरा हुआ या नहीं। इससे CapSolver CAPTCHA स्टेप पर फ़ोकस्ड रहता है और हर नेविगेशन समस्या को ऐसा challenge मानकर नहीं चलता जिसे यह सुलझा सके।

CapSolver के साथ भरोसेमंद Automation Workflows बनाएँ

जब आपकी authorized Patchright workflow को किसी supported CAPTCHA response की ज़रूरत हो, तो CapSolver आज़माएँ। solving को वास्तव में आने वाले challenge पर conditional रखें, और workload बढ़ाने से पहले परिणाम verify करें।

FAQ

प्रश्न: क्या Patchright अपने आप reCAPTCHA सॉल्व कर देता है?

नहीं। सिर्फ़ ब्राउज़र कंट्रोल से reCAPTCHA solution token नहीं मिलता। अगर आपकी authorized page को अभी भी CAPTCHA response की आवश्यकता है, तो कोई supported solving स्टेप जोड़ें या एप्लिकेशन की development testing configuration का उपयोग करें।

प्रश्न: एक दिखने वाला विजेट खाली detection result क्यों दे सकता है?

स्क्रिप्ट, उस JavaScript environment से अलग environment पढ़ रही हो सकती है जिसमें विजेट ने अपनी configuration initialize की। site key missing मानने से पहले initialization और main‑environment access की जाँच करें।

प्रश्न: क्या यह आधिकारिक Patchright इंटीग्रेशन है?

नहीं। यह आधिकारिक Patchright पैकेज और CapSolver SDK का उपयोग करने वाला इंटीग्रेशन example है। custom adapter और detection स्क्रिप्ट को सूचीबद्ध versions के साथ execute किया गया; पेड़ solving टेस्ट नहीं की गई।

प्रश्न: क्या मुझे लोकल setup check के लिए API key की ज़रूरत है?

नहीं। setup check public development विजेट के parameters पढ़ता है। अलग solving कॉल के लिए वैध API key और अकाउंट resources की ज़रूरत होती है।

प्रश्न: क्या मैं इस उदाहरण के साथ Firefox या WebKit का उपयोग कर सकता हूँ?
नहीं। Patchright दस्तावेज़ Chromium-आधारित ब्राउज़रों के लिए समर्थन देते हैं। उदाहरण अपना Chromium रनटाइम लॉन्च करता है।

प्र: क्या टोकन फिल-बैक का मतलब है कि फ़ॉर्म ने सत्यापन पास कर लिया?

नहीं। टोकन फिल-बैक और आवेदन स्वीकृति अलग-अलग परिणाम हैं। अपने वर्कफ़्लो को जारी रखने से पहले, आवश्यक कार्रवाई के बाद एप्लिकेशन की प्रतिक्रिया की जाँच करें।