reCAPTCHA v3 Score कैसे बेहतर करें: छह फ़िक्स जो काम करते हैं

आप reCAPTCHA v3 स्कोर सेट नहीं कर सकते। Google इसे प्रति रिक्वेस्ट असाइन करता है, और आपके कोड में कुछ भी इसे सीधे नहीं बदलता। आप जो बदल सकते हैं वह है जो इसे फीड करता है: आप action को कैसे नाम देते हैं, आप टोकन कब रिक्वेस्ट करते हैं, आपकी साइट का कितना हिस्सा वाकई reCAPTCHA चलाता है, और आपका बैकएंड नतीजे के साथ क्या करता है। इन्हें ठीक करें और डिस्ट्रीब्यूशन बदल जाएगा।
छह बदलाव, इस क्रम में कि ये आम तौर पर कितना मदद करते हैं। पहले मापें, क्योंकि जो आधी साइटें सोचती हैं कि उनमें scoring की समस्या है उनमें असल में threshold की समस्या है।
score का वास्तव में क्या मतलब है
v3 हर सत्यापन के साथ 0.0 और 1.0 के बीच एक संख्या लौटाता है। Google’s के शब्दों में: 1.0 का बहुत संभावना से एक अच्छा इंटरैक्शन होना, 0.0 का बहुत संभावना से एक बॉट होना। कोई checkbox और कोई पहेली नहीं है, इसलिए संख्या ही पूरा संकेत है।
उससे दो बातें निकलती हैं, और दोनों मायने रखती हैं:
- score है प्रति request और प्रति action, प्रति उपयोगकर्ता नहीं। वही visitor आपके homepage पर 0.9 और checkout पर 0.3 स्कोर कर सकता है।
- Google का सुझाया गया प्रारंभिक थ्रेशोल्ड है 0.5. यह एक default है जिससे दूर ट्यून करना है, न कि छूने का लक्ष्य।
अगर आप इसमें नए हैं कि v3 checkbox संस्करण से कैसे अलग है, तो हमारा explainer reCAPTCHA कैसे काम करता है तंत्र को कवर करता है।
कुछ भी बदलने से पहले मापें
reCAPTCHA admin console आपकी साइट के लिए एक score वितरण और आपके शीर्ष दस actions का ब्रेकडाउन दिखाता है। कोड छूने से पहले इसे देखें। आप तीन आकृतियों में से किसी एक की तलाश कर रहे हैं:
- सब कुछ 0.9 पर, और आप फिर भी लोगों को ब्लॉक कर रहे हैं। समस्या आपका threshold या आपका backend logic है, score नहीं।
- एक व्यापक फैलाव निचले सिरे पर एक उभार के साथ। सामान्य। threshold को प्रति action ट्यून करें।
- सब कुछ 0.1 से 0.3 पर। कुछ संरचनात्मक रूप से गलत है। आमतौर पर token, न कि traffic।
Google यह भी चेतावनी देता है कि staging में या v3 इंस्टॉल करने के तुरंत बाद के स्कोर प्रोडक्शन से अलग होते हैं, क्योंकि मॉडल के पास अभी साइट के लिए कोई इतिहास नहीं है। निष्कर्ष निकालने से पहले इसे एक हफ़्ते का असली ट्रैफ़िक दें। किसी एकल रिक्वेस्ट की अलग से जाँच करने के लिए, हमारा लाइव reCAPTCHA v3 टेस्ट पेज एक हल के लिए raw स्कोर लौटाता है।
फ़िक्स 1: अपने actions को नाम दें, और उन्हें सही नाम दें
यह सबसे बड़ी अकेली जीत है, और इसे अक्सर छोड़ दिया जाता है। Google हर action को अलग-अलग स्कोर करता है और action’s के अपने इतिहास को संदर्भ के रूप में उपयोग करता है। पूरी साइट पर एक सामान्य action का मतलब है एक मिला-जुला इतिहास, और हर पेज इसका सबसे बुरा हिस्सा विरासत में पाता है।
// One action per meaningful event. Not one for the whole site.
grecaptcha.ready(function () {
grecaptcha.execute("YOUR_SITEKEY", { action: "login" })
.then(function (token) {
document.getElementById("recaptcha-token").value = token;
});
});Google जो नियम लागू करता है: actions में सिर्फ़ alphanumeric अक्षर, slashes और underscores हो सकते हैं, और वे user-specific नहीं होने चाहिए। इसलिए checkout/payment ठीक है, checkout_user_8842 नहीं है। एक यूज़र-विशिष्ट action इतिहास को हज़ारों buckets में बाँट देता है जिनमें से किसी में कोई डेटा नहीं होता, जो actions को बिल्कुल नाम न देने से भी बुरा है।
सुधार 2: reCAPTCHA को केवल form के अलावा और जगह चलाएं
v3 व्यवहार को स्कोर करता है, और व्यवहार को एक से ज़्यादा data point की ज़रूरत होती है। अगर script केवल आपके login पेज पर लोड होती है, तो Google एक ऐसे विज़िटर को देखता है जो अचानक एक form पर प्रकट होकर सबमिट कर देता है, जो बिल्कुल वैसा ही दिखता है जैसा एक बॉट दिखता है।
Google’s खुद की सिफ़ारिश है कि v3 को पूरी साइट पर लोड करें, उन पेजों समेत जिन पर कोई फ़ॉर्म नहीं है। आपको उन पेजों पर सत्यापित करने की ज़रूरत नहीं। बस script को चलाने भर से मॉडल को कुछ काम करने के लिए मिल जाता है, जब तक visitor उस action तक पहुँचता है जिसकी आपको परवाह है।
यह वही सुधार है जिसे लोग गलती से पलट देते हैं। script को किसी ऐसे conditional में डालना जो केवल चेकआउट route पर चलता है, कुछ ही दिनों में आपके scores गिरा देगा।
फ़िक्स 3: token तब पाएं जब आप सबमिट करें, न कि पेज लोड पर
reCAPTCHA v3 tokens जारी होने’re के दो मिनट बाद एक्सपायर हो जाते हैं। एक इसमें जनरेट करें ready() पेज लोड पर, और कोई भी विज़िटर जो आपके form को उससे ज़्यादा देर तक पढ़ता है वह एक मृत token सबमिट करता है। आपका बैकएंड विफलता को कैसे संभालता है, उसके आधार पर, यह एक बुरे स्कोर या एक कठोर अस्वीकृति के रूप में पढ़ा जाता है।
// Solve on submit so the token is always fresh.
form.addEventListener("submit", function (e) {
e.preventDefault();
grecaptcha.execute("YOUR_SITEKEY", { action: "login" })
.then(function (token) {
tokenField.value = token;
form.submit();
});
});लंबे फॉर्म, मल्टी-स्टेप चेकआउट और फ़ाइल अपलोड वाली कोई भी चीज़ वहीं होती है जहाँ यह सबसे ज़्यादा चुभती है।
Fix 4: server side पर सत्यापित करें, और action भी जाँचें
जब तक आपका backend token को एक्सचेंज नहीं करता, तब तक वह बेकार है। वह एक्सचेंज score, action और एक hostname लौटाता है, और आपको तीनों की जांच करनी चाहिए।
# Exchange the token for the score. Server side only.
curl -X POST https://www.google.com/recaptcha/api/siteverify \
-d secret=YOUR_SECRET_KEY \
-d response=THE_TOKEN_FROM_THE_PAGE
# {"success":true,"score":0.9,"action":"login","hostname":"example.com"}अगर आप केवल जाँचते हैं success, आप v3 का उपयोग कर ही नहीं रहे हैं। success का मतलब है कि token पार्स हुआ, यह नहीं कि विज़िटर इंसान लगा। और अगर आप तुलना नहीं करते action उसके मुकाबले जो उस endpoint ने अपेक्षित किया था, आपके कम-मूल्य वाले newsletter form पर बना token आपके login endpoint पर ठीक काम करता है।
फिक्स 5: प्रति action एक थ्रेशोल्ड सेट करें, साइट के लिए एक नहीं
एक चेकआउट और एक न्यूज़लेटर साइनअप को एक ही cutoff साझा नहीं करना चाहिए। एक बार जब आपके पास प्रति action एक सप्ताह का डेटा हो, तो प्रत्येक को वहाँ सेट करें जहाँ आपका ट्रैफ़िक वास्तव में टिकता है।
| Action टाइप | उचित शुरुआती बिंदु | इसके नीचे क्या करना है |
|---|---|---|
| न्यूज़लेटर, सर्च, पेज व्यू | 0.3 | अनुमति दें, score लॉग करें |
| Login, comment | 0.5 | एक दूसरा factor या एक v2 checkbox जोड़ें |
| Checkout, password रीसेट | 0.7 | एक मैन्युअल challenge तक बढ़ें |
ध्यान दें कि उन पंक्तियों में से कोई भी “block” नहीं कहती। कम score पर hard-blocking करना ही वह तरीका है जिससे v3 deployments corporate VPNs और privacy browsers पर असली ग्राहकों को बाहर कर देते हैं। इसके बजाय challenge को बढ़ाएँ।
Fix 6: सामान्य score किलर्स को खारिज करें
अगर सभी संरचनात्मक सुधार लागू हैं और scores फिर भी कम हैं, तो इनसे होकर गुज़रें:
| कारण | यह कम स्कोर क्यों करता है |
|---|---|
| एक पेज पर दो reCAPTCHA scripts | दूसरा load पहले को मिटा देता है और token ग़लत context से बंध जाता है |
| Shared या datacenter IPs | Office NAT, VPNs और cloud egress सभी दूसरे लोगों’s का इतिहास लिए होते हैं |
| आक्रामक privacy extensions | ब्लॉक की गई कुकीज़ और स्टोरेज मॉडल को पढ़ने के लिए कुछ नहीं छोड़ते |
| Iframe वाले या एम्बेडेड फॉर्म | Cross-origin context signal को कमज़ोर करता है |
| Sitekey और domain बेमेल | जांचें hostname verify response में field |
एक चीज़ जो है नहीं इस सूची में: बैज छिपाना। यह एक CSS और एट्रिब्यूशन का सवाल है, और इसका स्कोरिंग पर कोई प्रभाव नहीं है। हमने इसे करने का अनुपालन-योग्य तरीका बताया है reCAPTCHA v3 badge को छिपाना.
वह समस्या जिसे tuning हल नहीं करेगी
अगर traffic स्वचालित है, तो वह कम स्कोर करता है क्योंकि v3 को यही पहचानने के लिए बनाया गया था। कितना भी action naming किसी headless browser को ठीक नहीं करता। अपनी खुद की site के परीक्षण के लिए, या ऐसे ऑटोमेशन के लिए जिसे चलाने की आपको अनुमति है, आप पेज के बजाय एक solver से token पाते हैं:
# pip install capskip
from capskip import CapSkip
solver = CapSkip(host="127.0.0.1", port=8080)
result = solver.recaptcha(
sitekey="YOUR_SITEKEY",
url="https://example.com/page-with-recaptcha",
version="v3",
action="login", # must match the page
)
print(result["code"]) # token, inject it and submitइस पर ध्यान दें action फिर से। यह इस ओर उतना ही मायने रखता है जितना आपकी ओर, ठीक उसी कारण से: बैकएंड इसकी तुलना करता है।
जो आप नहीं कर सकते वह है कोई score तय करना। solve request पर कोई minimum-score parameter नहीं है। यह संख्या Google’s का फ़ैसला है, जो तब बनता है जब आपका token सत्यापित होता है, इसलिए एक सॉल्वर आपको एक token देता है और उससे ज़्यादा कुछ नहीं।
अक्सर पूछे जाने वाले सवाल
मेरा reCAPTCHA v3 स्कोर हमेशा 0.1 क्यों रहता है?
सारे traffic में एक समान 0.1 लगभग कभी behaviour की समस्या नहीं होती। किसी duplicate script tag की जाँच करें, एक बासी token जो सबमिशन से दो मिनट से ज़्यादा पहले जारी हुआ हो, या किसी अलग domain पर register किया गया sitekey। The hostname verify response में field आख़िरी वाले को तुरंत तय कर देता है।
score में बदलाव दिखने में कितना समय लगता है?
कई दिन। model हर साइट और हर action के हिसाब से history का इस्तेमाल करता है, इसलिए कोई नया action बिना किसी context के शुरू होता है और जैसे-जैसे traffic जमा होता है वैसे-वैसे स्थिर होता जाता है। किसी बदलाव को एक दोपहर के data पर मत आंकिए।
क्या एक ऊँचा score threshold मेरी साइट को ज़्यादा सुरक्षित बनाता है?
बस एक हद तक, और इसकी कीमत आपको असली उपयोगकर्ताओं के रूप में चुकानी पड़ती है। हर endpoint को 0.9 तक बढ़ाना किसी दृढ़ हमलावर को रोकने से बहुत पहले साझा IPs और privacy browsers वाले लोगों को ब्लॉक कर देता है। threshold को प्रति action सेट करें और सीधे अस्वीकार करने के बजाय challenge को बढ़ाएँ।
क्या मैं बिना backend code लिखे score देख सकता हूं?
हाँ। admin console आपकी अपनी साइट के लिए वितरण दिखाता है, और हमारा v3 डेमो पेज एक single solve के लिए raw score लौटाता है ताकि आप एक request की तुलना उससे कर सकें जो आपका अपना endpoint रिपोर्ट करता है।
सारांश
प्रति इवेंट एक action नाम दें, पूरी साइट पर v3 लोड करें, सबमिट के समय टोकन बनाएँ, सर्वर साइड पर वेरिफाई करें और action की तुलना करें, फिर एक ग्लोबल कटऑफ के बजाय प्रति एंडपॉइंट एक थ्रेशोल्ड सेट करें। एडमिन कंसोल एक हफ़्ते बाद जाँचें, उसी दिन नहीं।
v3 स्कोरिंग की कार्यप्रणाली और उसके साथ आने वाले विकल्पों के लिए, देखें reCAPTCHA v3 हल, और Google’s अपना v3 documentation थ्रेशोल्ड और action नामकरण पर प्राधिकरण है। अगर आप अपने खुद के फॉर्म को एक कम स्कोर के विरुद्ध टेस्ट कर रहे हैं, तो CapSkip एक कैप्चा सॉल्वर जो लोकल रूप से चलता है, ताकि आप बिना किसी प्रति-हल बिल के पूरे दिन टोकन जेनरेट कर सकें।
