reCAPTCHA टोकन एक्सपायरी: टोकन कितनी देर वैध रहते हैं

reCAPTCHA token की एक्सपायरी दो मिनट है। Google का दस्तावेज़ इसे साफ़ कहता है: हर response token दो मिनट तक वैध है और उसे सिर्फ़ एक ही बार सत्यापित किया जा सकता है। इन दोनों में से कोई भी आधा हिस्सा चूकिए और आपके server को वही बेकार सी error वापस मिलती है। यह पोस्ट उन तीन अलग-अलग घड़ियों को देखती है जिन्हें लोग एक ही समझ बैठते हैं, यह भी कि किसी स्वचालित flow में वे 120 सेकंड असल में कहाँ जाते हैं, और वह क्रम बदलने वाली तरकीब जो expired-token के लगभग हर bug को ठीक कर देती है।

दो मिनट, और ठीक एक बार सत्यापन

नियम के दो हिस्से हैं और दोनों काटते हैं।

दो मिनट। घड़ी तब शुरू होती है जब token जारी होता है, तब नहीं जब आपका form सबमिट होता है। जो token किसी hidden field में पड़ा रहता है जबकि उपयोगकर्ता टाइप करना पूरा कर रहा होता है, वह पहले ही अपना बजट खर्च कर रहा होता है।

एक सत्यापन। वही token Google को दूसरी बार भेजने पर दूसरी बार विफल होता है, चाहे एक सेकंड बाद ही क्यों न हो। यह जानबूझकर है: यही किसी पकड़े गए token को दोबारा चलाए जाने से रोकता है। अगर आपका backend एक बार किसी middleware में सत्यापित करता है और दोबारा handler में, तो दूसरी कॉल विफल हो जाती है और bug रुक-रुक कर आता हुआ दिखता है।

दोनों विफलताएँ एक ही चीज़ लौटाती हैं। Google के सत्यापन response में success false आता है और error code यह होता है: timeout-or-duplicate, जिसका मतलब है कि response या तो बहुत पुराना है या पहले इस्तेमाल हो चुका है। यह नहीं बताता कि दोनों में से कौन सा, इसलिए इन्हें एक ही bug श्रेणी मानें और दोनों जाँचें।

तीन घड़ियाँ, एक नहीं

यहाँ ज़्यादातर उलझन तीन अलग-अलग timers को एक ही “token expiry” के विचार में समेट देने से आती है। ये अलग-अलग हैं और अलग-अलग ही खत्म होते हैं।

पहली वाली को लोग कभी आते हुए नहीं देखते, क्योंकि वह client की तरफ़ है और चुपचाप होती है। v2 checkbox पर widget दो मिनट बाद अपने ही जवाब को अमान्य कर देता है और उस function को कॉल करता है जिसे आपने expired callback के रूप में दर्ज किया था। अगर आपने कुछ दर्ज ही नहीं किया, तो स्क्रीन पर टिक लगा box टिका ही रहता है जबकि उसके पीछे का hidden field खाली होता है, इसलिए form बिना किसी token के पोस्ट होता है और server expired नहीं, बल्कि missing-input वाली error बताता है।

<!-- Register the callback. Without it the box looks ticked
     while the value behind it is already gone. -->
<div class="g-recaptcha"
     data-sitekey="YOUR_SITEKEY"
     data-callback="onSolved"
     data-expired-callback="onExpired"></div>

<script>
function onExpired() {
  // Reset the widget and re-enable whatever you disabled.
  grecaptcha.reset();
}
</script>

दूसरी चुनौतियाँ कितनी देर चलती हैं?

दो मिनट हर जगह लागू नहीं होते। अगर आप एक से ज़्यादा चुनौती प्रकार संभालते हैं, तो बजट इतने अलग हैं कि फ़र्क़ पड़ता है।

Turnstile सबसे उदार है। Cloudflare की server-side validation गाइड एक token को 300 सेकंड देती है और दोबारा चलाए गए token को उसी timeout-or-duplicate कोड के साथ ठुकरा देती है जो Google इस्तेमाल करता है। GeeTest v3 उल्टी तरफ़ से काम करता है: जो challenge मान आप solve में देते हैं वह एक ही बार इस्तेमाल के लिए है और लगभग एक मिनट में एक्सपायर हो जाता है, इसलिए समय-सीमा solve के बाद नहीं, बल्कि उससे पहले है। इसे हल करने से ठीक पहले लाएँ, कभी किसी script की शुरुआत में नहीं।

वे दो मिनट असल में कहाँ जाते हैं

हाथ से भरे जाने वाले form में यह बजट बहुत बड़ा है। किसी स्वचालित flow में यह दिखने से कहीं ज़्यादा तंग है, क्योंकि हल होना तत्काल नहीं होता।

पचानवे सेकंड की गुंजाइश तब तक आरामदायक है जब तक बीच में कुछ और न आ बैठे। आम वजहें हैं एक proxy handshake, solve और submit के बीच घुसा हुआ कोई login चरण, कोई rate limiter जो आपके worker को सुला देता है, या कोई queue जो हल किए गए tokens को बाद में इस्तेमाल के लिए इकट्ठा करती है। आख़िरी वाला कभी काम नहीं करता: token एक जल्दी खराब होने वाली चीज़ है, ऐसा संसाधन नहीं जिसे आप pool में रख सकें।

token सबसे आख़िर में लें

expired-token वाले लगभग हर bug का इलाज क्रम है। धीमा सारा काम पहले कर लें, और token को उस request से ठीक पहले, आख़िरी चरण के रूप में लें जो उसे खर्च करती है।

# pip install capskip
from capskip import CapSkip

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

# Slow things first: log in, warm the session, pick up cookies.
session = build_session()
sitekey = read_sitekey(session, PAGE_URL)

# Then solve, so the clock starts as late as possible.
result = solver.recaptcha(sitekey=sitekey, url=PAGE_URL)

# And submit straight away. Nothing goes between these two lines.
session.post(PAGE_URL, data={"g-recaptcha-response": result["code"]})

इससे दो नियम निकलते हैं, और वे बाकी ज़्यादातर बातें ढक लेते हैं।

• token को कभी cache न करें। न Redis में, न किसी ऐसे variable में जो request से ज़्यादा जीता हो, न किसी retry के आर-पार। इसके बजाय दोबारा हल करें
• दो बार कभी सत्यापित न करें। ठीक एक ही जगह सत्यापित करें। अगर किसी middleware ने token पहले ही जाँच लिया है, तो route handler को Google को दोबारा कॉल करने के बजाय वही नतीजा पढ़ना चाहिए

Retries अपने आप में एक बात के हक़दार हैं। अगर submit विफल होता है और आप उसे दोबारा आज़माते हैं, तो जो token आप पहले भेज चुके हैं वह खर्च हो चुका है, इसलिए retry को एक नए solve की ज़रूरत है। पूरे काम की इकाई को दोबारा चलाना सही है। सिर्फ़ HTTP कॉल को पुराने token के साथ दोबारा चलाने पर हर बार timeout-or-duplicate मिलेगा और लगेगा जैसे सॉल्वर ग़लत जवाब लौटा रहा हो।

Latency, और सॉल्वर कहाँ चलता है

चूँकि CapSkip आपके अपने hardware पर चलता है, दो मिनट के बजट का कोई हिस्सा इंटरनेट के पार किसी तीसरे पक्ष के endpoint तक पहुँचने में खर्च नहीं होता। Local मोड 127.0.0.1 पर सुनता है और कॉल कभी मशीन से बाहर जाती ही नहीं।

Server मोड इसे थोड़ा बदलता है और यह जानना काम का है कि कितना। अपने workers को network पर या public IP वाले किसी VPS पर बैठे साझा सॉल्वर की ओर मोड़ने से हर कॉल पर एक network hop जुड़ता है, जो LAN पर मिलीसेकंड भर है और उसी region के VPS तक दसियों मिलीसेकंड। 120 सेकंड के मुक़ाबले यह शोर भर है, और बदले में आपको एक सॉल्वर मिलता है जो पूरे बेड़े को सेवा देता है। दोनों मोड यहीं कॉन्फ़िगर होते हैं: कनेक्शन सेटिंग्स, और server वाले मामले के लिए एक static public IP की सलाह दी जाती है।

CapSkip का एक ब्योरा भी यहीं आता है: हल किया गया नतीजा एक ही बार पढ़ा जा सकता है। उसी job id को दूसरी बार poll करने पर जवाब दोबारा नहीं मिलेगा, इसलिए token को पहली बार पढ़ते ही सहेज लें, बाद में दोबारा लाने की कोशिश न करें।

FAQ

संक्षेप में

दो मिनट, एक सत्यापन, और तीन अलग-अलग घड़ियाँ जिन्हें लोग एक ही समझ बैठते हैं। expired callback दर्ज करें ताकि browser वाला मामला दिखाई दे, जितनी देर से हो सके उतनी देर से हल करें, और token को कभी cache या replay न करें। चूँकि दोबारा हल करना तब मुफ़्त पड़ता है जब सॉल्वर आपका अपना हो, यानी एक लोकल captcha सॉल्वर, किसी expired token का सही जवाब हमेशा दोबारा हल करना ही है। हर version की कार्यप्रणाली के लिए देखें reCAPTCHA v2 गाइड और v3 गाइड, Turnstile पेज पाँच मिनट वाले मामले के लिए, और reCAPTCHA क्या है पृष्ठभूमि के लिए।