Python में GeeTest v3 कैसे हल करें और उसे वापस पोस्ट करें

ज़्यादातर कैप्चा कोड यह मानता है कि एक token अंदर, एक token बाहर। GeeTest इसे तोड़ देता है। एक solve लौटाता है तीन ऐसी values जिन्हें एक साथ सबमिट करना ज़रूरी होता है, और आपने जो challenge दिया वह उसे फ़ेच करने के लगभग साठ सेकंड बाद एक्सपायर हो जाता है। ये दोनों लोगों को उलझा देते हैं, और इनमें से कोई भी किसी सहायक संदेश के साथ विफल नहीं होता।

दो inputs जो अलग-अलग व्यवहार करते हैं

Value	आजीवन
gt	साइट के लिए स्थिर। इसे स्वतंत्र रूप से कैश करें
challenge	Single use, लगभग 60 सेकंड में समाप्त

दोनों साइट’s के अपने GeeTest init endpoint से आते हैं। यह gt प्रभावी रूप से एक साइट पहचानकर्ता है। वह challenge प्रति प्रयास होता है, और इसे दोबारा उपयोग योग्य मानना ही अकेला सबसे आम कारण है कि एक GeeTest इंटीग्रेशन टेस्टिंग में काम करता है और लोड में बिखर जाता है।

Setup

# Python 3.10 or newer.
pip install capskip

from capskip import CapSkip

solver = CapSkip(
    host="127.0.0.1",
    port=8080,
    recaptchaTimeout=300,   # GeeTest uses this, not defaultTimeout
)

वह timeout का अंतर आसानी से छूट जाता है। defaultTimeout केवल image कैप्चा को नियंत्रित करता है; सब कुछ interactive इस्तेमाल करता है recaptchaTimeout.

Solving

result = solver.geetest(
    gt="81388ea1fc187e0c335c0a8907ff2625",
    challenge="7cf6a8b1a2c34d5e6f7089abcdef0123",
    url="https://example.com/login",
)

print(result["challenge"])
print(result["validate"])
print(result["seccode"])

वे तीन keys ही answer हैं। result["code"] यह भी भरा जाता है, पर GeeTest के लिए इसमें submit करने लायक कुछ के बजाय raw JSON string होती है, इसलिए आदतन इसकी ओर हाथ बढ़ाना एक भ्रमित करने वाली विफलता पैदा करता है।

इसका उपयोग करें the challenge जो वापस आता है, वह नहीं जो आपने भेजा था। वे हमेशा एक ही मान नहीं होते।

पूरा फ्लो, एक ही जगह

fetching और solving को साथ-साथ होना चाहिए। इनके बीच कोई भी धीमी चीज़ समाप्ति का जोखिम पैदा करती है:

import time
import requests
from capskip import CapSkip

solver = CapSkip()
LOGIN = "https://example.com/login"

# 1. Fresh pair, cache-busted. Cached init responses hand back dead challenges.
init = requests.get(
    "https://example.com/geetest/init",
    params={"t": int(time.time() * 1000)},
).json()

# 2. Solve immediately. Do not queue this.
result = solver.geetest(gt=init["gt"], challenge=init["challenge"], url=LOGIN)

# 3. Post all three together, alongside the real form fields.
response = requests.post(LOGIN, data={
    "geetest_challenge": result["challenge"],
    "geetest_validate": result["validate"],
    "geetest_seccode": result["seccode"],
    "username": "...",
    "password": "...",
})

cache-busting टाइमस्टैम्प दिखने से ज़्यादा मायने रखता है। GeeTest init endpoints अक्सर किसी CDN या प्रॉक्सी द्वारा कैश कर लिए जाते हैं, और एक कैश की गई response आपको ऐसा challenge देती है जो पहले ही खर्च हो चुका होता है।

वे तीनों field नाम सामान्य GeeTest v3 परंपरा हैं, लेकिन कोई site उनका नाम बदल सकती है। मान लेने से पहले असली form जांचें।

एक साथ कई करना

यहाँ फंसाने वाली बात है ग़लत तरीक़े से batching करना। ढेर सारे challenges fetch करके फिर उन सबको हल करना यह पक्का कर देता है कि बाद वाले अपनी बारी से पहले ही expire हो जाएंगे। एक ही task के अंदर fetch और हल करें:

import asyncio
from capskip import AsyncCapSkip

async def solve_one(solver, url):
    init = await fetch_pair(url)          # your own fetch, awaited
    return await solver.geetest(
        gt=init["gt"], challenge=init["challenge"], url=url,
    )

async def main():
    solver = AsyncCapSkip()
    return await asyncio.gather(*[solve_one(solver, u) for u in urls])

asyncio.run(main())

Python ही एकमात्र CapSkip SDK है जहाँ AsyncCapSkip यह किसी alias के बजाय एक असली async client है, इसलिए यह वाकई हल parallel में चलाता है।

जब यह फेल होता है

from capskip import (
    ValidationException, NetworkException, ApiException, TimeoutException,
)

try:
    result = solver.geetest(gt=gt, challenge=challenge, url=page_url)
except ValidationException:
    pass   # missing gt or challenge
except NetworkException:
    pass   # CapSkip is not running
except ApiException:
    pass   # usually a challenge that expired before the solve finished
except TimeoutException:
    pass   # exceeded recaptchaTimeout

व्यवहार में ज़्यादातर GeeTest विफलताएँ इस रूप में आती हैं ApiException और इसका मतलब है कि challenge मर गया। इसका हल है बाद में fetch करना, उसी जोड़ी के साथ retry करना नहीं, क्योंकि एक खर्च हो चुका challenge फिर कभी वैध नहीं होता।

अक्सर पूछे जाने वाले सवाल

result[“code”] उपयोग योग्य क्यों नहीं है?

क्योंकि उत्तर एक के बजाय तीन मान होता है। code पूर्णता के लिए raw JSON रखता है जबकि SDK उपयोगी हिस्सों को विस्तारित कर देता है challenge, validate और seccode. उन तीनों को सबमिट करें।

क्या मैं runs के बीच challenge को cache कर सकता हूँ?

नहीं। यह single use है और लगभग एक मिनट में समाप्त हो जाता है। gt कैश करना सुरक्षित है; challenge कभी नहीं होता।

क्या यह GeeTest v4 को कवर करता है?

The geetest method v3 को लक्ष्य करता है, वह slide puzzle जो के इर्द-गिर्द बना है gt और challenge जोड़ी। v4 ने पैरामीटर model बदल दिया, इसलिए मौजूदा जांचें API डॉक्युमेंटेशन यह मानने से पहले कि वही कॉल लागू होती है।

सारांश

Fetch gt और challenge cache-busted रिक्वेस्ट के साथ हल करने से ठीक पहले, कॉल करें geetest, फिर पोस्ट करें challenge, validate और seccode एक साथ। अपने input के बजाय लौटाए गए challenge का उपयोग करें, और हल करने से पहले challenge fetching को कभी batch न करें।

अन्य भाषाएँ इस पर हैं GeeTest solver page, व्यापक Python surface इस पर Python कैप्चा सॉल्वर पेज, और हमारे यहाँ एक लाइव पहेली है GeeTest v3 demo। CapSkip संभालता है कैप्चा बायपास लोकल रूप से, इसलिए हल का वॉल्यूम मुफ़्त है।