अल्टीमेट WebAuthn एरर इन प्रोडक्शन गाइड (2026)

उत्पादन (production) में, WebAuthn त्रुटियाँ भ्रमित करने वाली होती हैं क्योंकि ब्राउज़र DOMException नामों का एक छोटा सा सेट (जैसे NotAllowedError) उजागर करते हैं जो कई अंतर्निहित कारणों का प्रतिनिधित्व कर सकते हैं। इसके अलावा, अधिकांश "त्रुटियाँ" - अनुकूलित बड़े पैमाने की तैनाती में अक्सर 95% से ऊपर - वास्तव में अपेक्षित व्यवहार (उपयोगकर्ता ने ऑपरेटिंग सिस्टम पासकी (passkey) प्रॉम्प्ट को रद्द कर दिया) होती हैं।

Passkeys Debugger में passkey flows के साथ experiment करें.

मुफ्त में आज़माएं

यदि आप इन नामों के लिए विहित परिभाषाएँ चाहते हैं, तो MDN DOMException से प्रारंभ करें। WebAuthn-विशिष्ट स्थितियों के लिए जो इन अपवादों को जन्म देती हैं (और ब्राउज़र को क्या लागू करना आवश्यक है), W3C Web Authentication spec देखें।

यदि आप सभी त्रुटियों को "बग" के रूप में मानते हैं, तो आप गलत काम करेंगे:

• आप सामान्य कैंसल के साथ अपने त्रुटि मेट्रिक्स को प्रदूषित करेंगे
• आप NotAllowedError के ढेर के अंदर छिपे वास्तविक प्रतिगमन को याद करेंगे
• आप ऐसा UI शिप करेंगे जो उपयोगकर्ताओं को पुनर्प्राप्त करने में मदद करने के बजाय उन्हें भ्रमित करता है

इस लेख में हम उत्तर देते हैं:

• वास्तविक ट्रैफ़िक में सबसे सामान्य WebAuthn त्रुटि नामों का आमतौर पर क्या अर्थ होता है?
• आप NotAllowedError को कार्रवाई योग्य बकेट (कैंसल बनाम टाइमआउट बनाम उपलब्धता) में कैसे अलग करते हैं?
• एक ही त्रुटि का ऑपरेशन (सशर्त UI लॉगिन बनाम मोडल लॉगिन बनाम पासकी निर्माण बनाम सशर्त निर्माण) के आधार पर अलग-अलग अर्थ क्यों होता है?
• आपको कौन सा न्यूनतम संदर्भ कैप्चर करना चाहिए ताकि "यह विफल रहा" एक पुनरुत्पादनीय समस्या बन जाए?

यदि आपको डीबगिंग को अनब्लॉक करने के लिए केवल एक त्वरित मैपिंग की आवश्यकता है, तो इस तालिका से प्रारंभ करें। यह इस बात की ओर पक्षपाती है कि टीमें वास्तव में डैशबोर्ड और सपोर्ट टिकटों में क्या देखती हैं।

एक चीज जिसे याद करना आसान है: एक ही error.name का ऑपरेशन प्रकार के आधार पर बहुत अलग अर्थ हो सकता है। नीचे दिए गए अनुभागों को पढ़ते समय ऑपरेशन संदर्भ को ध्यान में रखें। व्यवहार में, पासकी निर्माण (पंजीकरण) त्रुटियां आमतौर पर बड़े अंतर से लॉगिन त्रुटियों से अधिक होती हैं - उपरोक्त तालिका दोनों पर लागू होती है, लेकिन निर्माण वह जगह है जहां अधिकांश मात्रा रहती है।

आगे, हम NotAllowedError पर गहराई से जाएंगे क्योंकि यह वह है जिसे आप सबसे ज्यादा देखेंगे और जिसे टीमें सबसे अधिक बार गलत समझती हैं।

NotAllowedError अक्सर "पासकी विफल" जैसा दिखता है, लेकिन यह आमतौर पर प्लेटफ़ॉर्म आपको यह बता रहा होता है कि उपयोगकर्ता ने OS UI को पूरा नहीं किया। मुख्य बात यह है कि इसे उन बकेट में विभाजित किया जाए जिन पर आप कार्रवाई कर सकते हैं।

आप ब्राउज़र कंसोल में क्या देखेंगे:

ये सभी error.name === "NotAllowedError" के रूप में सामने आते हैं। error.message ब्राउज़र इंजन और अंतर्निहित कारण के अनुसार भिन्न होता है, लेकिन परिणाम समान होता है: समारोह पूरा नहीं हुआ।

यह लॉगिन और पासकी निर्माण दोनों पर लागू होता है। लॉगिन (सशर्त UI, अनुमति सूची के साथ या उसके बिना मोडल) के दौरान, NotAllowedError का आमतौर पर मतलब है कि उपयोगकर्ता ने समारोह पूरा नहीं किया। पासकी निर्माण के दौरान, वही त्रुटि अलग-अलग कारणों से सामने आती है: उपयोगकर्ता ने निर्माण संवाद को खारिज कर दिया (सशर्त निर्माण काम नहीं किया, या ऑटो-ट्रिगर अपेंड के दौरान पृष्ठ ने फोकस खो दिया)। ऑपरेशन प्रकार यह बदल देता है कि त्रुटि का क्या अर्थ है और आपको इसके बारे में क्या करना चाहिए।

समय अक्सर एक कम आंका गया संकेत है। एक क्लिक के एक सेकंड से भी कम समय के बाद त्रुटि आमतौर पर एक तत्काल अस्वीकृति होती है (वातावरण ऐसा नहीं कर सकता, दस्तावेज़ केंद्रित नहीं है, क्षमता का अभाव है)। कुछ सेकंड के बाद एक त्रुटि एक उपयोगकर्ता कैंसल है (उन्होंने संवाद देखा और आगे न बढ़ने का फैसला किया)। 30+ सेकंड के बाद एक त्रुटि एक टाइमआउट है। नेटिव प्लेटफ़ॉर्म पर, समय विशेष रूप से महत्वपूर्ण है: ऑथेंटिकेटर राउंड-ट्रिप, बायोमेट्रिक प्रॉम्प्ट और क्रेडेंशियल मैनेजर हैंडऑफ़ सभी की विशिष्ट अवधि होती है जो आपको "उपयोगकर्ता दूर चला गया" से "काम नहीं किया" को अलग करने में मदद करती है। आप अभी भी आसानी से अंतर नहीं कर सकते हैं यदि एक पासकी मौजूद थी।

आपको एक आदर्श संकेत की आवश्यकता नहीं है। आपको हर NotAllowedError को समान तरीके से मानने से बचने के लिए पर्याप्त संदर्भ की आवश्यकता है। iOS/Safari पर नीचे विशेष ध्यान दिया गया है क्योंकि इसमें अद्वितीय बाधाएं हैं (पहले के संस्करणों में उपयोगकर्ता सक्रियण आवश्यकताएं), लेकिन कच्चे त्रुटि मात्रा में, Windows और Chromium ब्राउज़र अक्सर किसी भी अन्य प्लेटफ़ॉर्म की तुलना में अधिक NotAllowedError उत्पन्न करते हैं। ये संकेत अक्सर आपको 80% रास्ते तक ले जाते हैं:

यही कारण है कि NotAllowedError उपयोगकर्ता को शायद ही कभी दिखाई देनी चाहिए। यह ऐसा संदेश नहीं है जिस पर उपयोगकर्ता कार्रवाई कर सके।

संदर्भ वर्गीकरण वह भी है जहां सफलता दर सबसे तेजी से विभाजित होती है। Corbado Passkey Benchmark 2026 पासकी प्रमाणीकरण सफलता दर विश्लेषण बड़े पैमाने पर B2C परिनियोजन में ज्ञात-डिवाइस रिटर्न के लिए 95–99% की तुलना में अज्ञात-डिवाइस पहचानकर्ता-प्रथम प्रवाह के लिए 55–95% पर Q1 2026 समापन को मापता है। iOS वेब पहचानकर्ता-प्रथम 85–95% समापन (% CDA 0–5%) पर, Android वेब 70–85% (% CDA 5–10%) पर और macOS वेब 70–85% (% CDA 10–15%) पर है, जबकि Windows वेब 45–60% पहचानकर्ता-प्रथम समापन पर बैठता है जिसमें Windows 11 पर % CDA 55–65% और Windows 10 पर 40–55% है। ज्ञात बनाम अज्ञात डिवाइस संदर्भों को अलग किए बिना NotAllowedError वॉल्यूम पढ़ना दो मौलिक रूप से भिन्न सफलता व्यवस्थाओं को मिलाता है।

उत्पादन में एक बात जो मायने रखती है: कुछ उपयोगकर्ता एजेंट टाइमआउट को TimeoutError के रूप में सामने ला सकते हैं, लेकिन कई टीमें अभी भी डैशबोर्ड में NotAllowedError में टाइमआउट को ढहते हुए देखती हैं। किसी भी तरह से, टाइमआउट को "समारोह पूरा नहीं हुआ" के रूप में मानें और समय और संदर्भ का उपयोग करके बकेट करें।

जब OS शीट को खारिज कर दिया जाता है या टाइम आउट हो जाता है, तो आपका UI तुरंत पुनर्प्राप्त होना चाहिए और शालीनता से प्रतिक्रिया करनी चाहिए। नियमों का एक व्यावहारिक सेट:

• लॉगिन UI पुनर्स्थापित करें (कोई स्पिनर नहीं जो चलता रहे)
• पहचानकर्ता स्थिति रखें (पुनः प्रविष्टि के लिए बाध्य न करें)
• उसी स्क्रीन पर एक दृश्यमान फ़ॉलबैक दिखाएं
• अपेक्षित परिणामों के लिए डरावने बैनरों से बचें

मूल बातों से परे:

• पहले निरस्त को सामान्य मानें और एक शांत स्पष्टीकरण के साथ पुनः प्रयास की पेशकश करें। केवल दूसरे गर्भपात के बाद ही आपको फ़ॉलबैक विकल्पों का सुझाव देना चाहिए (पासकी फ़ॉलबैक और पुनर्प्राप्ति देखें)।
• कूलडाउन से पहले तीन तक निर्माण प्रॉम्प्ट की अनुमति दें ताकि हैरान उपयोगकर्ताओं को दूसरा मौका मिले (पासकी निर्माण सर्वोत्तम अभ्यास देखें)।
• त्रुटि की गणना को निर्माण और लॉगिन के बीच विभाजित करें ताकि आप तुलना कर सकें।
• OS, ब्राउज़र और डिवाइस द्वारा त्रुटि दर को विभाजित करें ताकि आप जान सकें कि वास्तव में घर्षण कहां रहता है (पासकी लॉगिन सर्वोत्तम अभ्यास देखें)।

यदि आपके "कैंसल" वास्तव में अधिक हैं, तो अगला कदम उनके पीछे के मूल कारणों को ठीक करना है: प्रॉम्प्ट समय, QR आश्चर्य और कम उपलब्धता।

उन परिवर्तनों के साथ प्रारंभ करें जो मेट्रिक्स को जल्दी ले जाते हैं:

• प्रॉम्प्ट समय और उपयोगकर्ता सक्रियता (विशेष रूप से iOS/Safari पर) ठीक करें: Safari WebAuthn उपयोगकर्ता-सक्रिय ईवेंट।
• QR/हाइब्रिड आश्चर्य कम करें: पासकी प्रवाह QR कोड क्यों दिखाते हैं और उपयोगकर्ता क्यों छोड़ देते हैं।
• ऑफ़र गेट करें ताकि पासकी तब दिखाई जाए जब उनके सफल होने की संभावना हो: पासकी केवल तभी ऑफ़र करें जब उनके सफल होने की संभावना हो।
• ऐसे पैटर्न का उपयोग करें जो कोई स्थानीय क्रेडेंशियल मौजूद न होने पर प्रॉम्प्ट करने से बचते हैं: WebAuthn तत्काल मध्यस्थता।
• नेटवर्क फ्लेकीनेस संभालें: सत्यापन के दौरान नेटवर्क त्रुटियां अक्सर सामान्य क्लाइंट-साइड विफलताओं के रूप में प्रकट होती हैं। अपने टेलीमेट्री लॉग के लिए एक ऑफ़लाइन कतार लागू करें ताकि जब समारोह के दौरान उपयोगकर्ता का कनेक्शन टूट जाए तो आप त्रुटि डेटा न खोएं।
• डिटेक्शन API के साथ सेरेमनी को गेट करें ताकि पर्यावरण विफलताएं आपके NotAllowedError बकेट को न बढ़ाएं। सबसे बुनियादी गेट के रूप में isUVPAA() के साथ प्रारंभ करें, फिर बारीक जांच (सशर्त निर्माण, सशर्त गेट, हाइब्रिड ट्रांसपोर्ट, प्लेटफ़ॉर्म ऑथेंटिकेटर) के लिए getClientCapabilities() का उपयोग करें। ध्यान रखें कि डिटेक्शन API OS अपडेट के साथ टूट सकते हैं: iOS 26.2 में एक WebKit बग आया जहाँ isUVPAA() सभी WKWebView-आधारित ब्राउज़रों पर false लौटाता है, भले ही पासकी ठीक से काम कर रही हों, जिससे 10-25% iOS उपयोगकर्ताओं के लिए अचानक NotAllowedError स्पाइक्स हो जाते हैं (getClientCapabilities() के साथ पासकी डिटेक्शन को ठीक करना देखें)।

त्रुटि नाम एक गतिशील लक्ष्य हैं। अधिक दानेदार WebAuthn त्रुटियों को जोड़ने के लिए चल रहे प्रस्ताव हैं (उदाहरण के लिए, "कोई क्रेडेंशियल उपलब्ध नहीं है" को "उपयोगकर्ता ने रद्द कर दिया" से अलग करने के लिए)। फरवरी 2026 तक, यह किसी भी ब्राउज़र में लागू नहीं किया गया है, इसलिए संदर्भ और समय के आधार पर अपने स्वयं के कारण बकेट बनाना अभी भी उचित है। यदि आप इस काम को ट्रैक करना चाहते हैं, तो WebAuthn issue #2062 और "New Error Codes" explainer देखें।

शेष त्रुटि नाम कम होते हैं लेकिन फिर भी वे जब सामने आते हैं तो समझने योग्य होते हैं।

AbortError, NotAllowedError की तुलना में मात्रा में असामान्य है, लेकिन जब यह प्रकट होता है तो यह अत्यधिक नैदानिक होता है: इसका आमतौर पर मतलब है कि समारोह समाप्त नहीं हुआ क्योंकि आपके ऐप ने अनुरोध को अमान्य कर दिया - नेविगेशन हुआ, स्थिति बदल गई, या दूसरा अनुरोध शुरू हो गया।

आप ब्राउज़र कंसोल में क्या देखेंगे:

सामान्य उत्पादन कारणों में शामिल हैं:

• कई समवर्ती WebAuthn कॉल (दो प्रॉम्प्ट रेसिंग)
• एक इन-फ़्लाइट समारोह के दौरान मार्ग परिवर्तन/री-रेंडर
• रिट्री या स्टेट क्लीनअप के दौरान AbortController.abort() को कॉल करना

इसे ठीक करने के लिए, समारोह को एक "महत्वपूर्ण खंड" बनाने पर ध्यान दें:

• एक समय में केवल एक इन-फ़्लाइट अनुरोध की अनुमति दें
• समारोह के दौरान नेविगेशन को रोकें (या स्पष्ट रूप से रद्द करें और UI पुनर्स्थापित करें)
• गर्भपात को अपेक्षित नियंत्रण प्रवाह के रूप में मानें: एक पुनः प्रयास बटन और एक फ़ॉलबैक विधि दिखाएं

यदि आप एम्बेडेड सतहों या मल्टी-डोमेन ऐप्स में केंद्रित AbortError देखते हैं, तो जांच करने के लिए अगली बकेट SecurityError है।

SecurityError वह ब्राउज़र है जो आपको बता रहा है: "इस संदर्भ को आपने जो पूछा है उसे करने की अनुमति नहीं है।" व्यवहार में यह लगभग हमेशा कॉन्फ़िगरेशन होता है, उपयोगकर्ता का व्यवहार नहीं। परिपक्व उत्पादन तैनाती में, SecurityError दुर्लभ है क्योंकि ये समस्याएं आमतौर पर एकीकरण परीक्षण के दौरान पकड़ी जाती हैं। यदि यह उत्पादन में प्रकट होता है, तो इसका आमतौर पर मतलब है कि एक नया डोमेन, एम्बेडिंग संदर्भ, या परिनियोजन लक्ष्य उचित WebAuthn कॉन्फ़िगरेशन के बिना जोड़ा गया था।

सामान्य कारणों में शामिल हैं:

• RP ID / ओरिजिन बेमेल (मल्टी-डोमेन सेटअप)
• क्रॉस-ओरिजिन एम्बेडिंग प्रतिबंध (iframe)
• असुरक्षित संदर्भ (HTTPS नहीं) या अवरुद्ध अनुमतियां/नीतियां
• .well-known/webauthn या .well-known/assetlinks.json गलत कॉन्फ़िगर किया गया है, गायब है, या अस्थायी रूप से अनुपलब्ध है। उस महत्वपूर्ण विंडो के दौरान नेटवर्क समस्याएं जब ब्राउज़र इन फ़ाइलों को प्राप्त करता है, विफलताओं का कारण बनेंगी। एक सामान्य अंधा स्थान: यदि आपका होमपेज रखरखाव के लिए डाउन है, तो well-known फाइलें भी ऑफ़लाइन हैं, जो उन पर निर्भर करने वाले सभी आश्रित पक्षों में पासकी समारोहों को तोड़ देती हैं।

आप ब्राउज़र कंसोल में क्या देखेंगे:

उत्पादन में, SecurityError दुर्लभ हैं - इन्हें लगभग हमेशा एकीकरण परीक्षण के दौरान पकड़ा जाता है। जब वे दिखाई देते हैं, तो TLS प्रमाणपत्र त्रुटि सबसे आम उत्तरजीवी है।

सबसे तेज़ डीबगिंग लूप है:

• आपके द्वारा उपयोग किए गए ओरिजिन और RP ID इनपुट को लॉग करें
• उसी संदर्भ में पुनरुत्पादन करें (शीर्ष-स्तर बनाम iframe, prod डोमेन बनाम स्टेजिंग)
• यदि आप लॉगिन एम्बेड करते हैं, तो पुष्टि करें कि अनुमतियां नीति कॉन्फ़िगर की गई है (उदाहरण के लिए publickey-credentials-create / publickey-credentials-get): MDN Permissions-Policy
• अपनी डोमेन रणनीति को सत्यापित करें (संबंधित ओरिजिन देखें)
• यदि आप iframes का उपयोग करते हैं, तो सुविधा नीतियों को मान्य करें (iframe पासकी देखें)

एक बार SecurityError को संभाल लिया जाता है, गंभीरता से इलाज करने वाली अगली बकेट त्रुटियों का सेट है जो अक्सर कार्यान्वयन बग का संकेत देती है: InvalidStateError, ConstraintError और DataError।

Passkeys चीटशीट. passkey कार्यक्रमों के लिए व्यावहारिक मार्गदर्शन, रोलआउट पैटर्न और KPIs।

Cheat sheet पाएं

एक परिपक्व पासकी कार्यान्वयन में ये त्रुटियां दुर्लभ होनी चाहिए। जब वे दिखाई देते हैं, तो वे आम तौर पर संकेत देते हैं कि किसी खंड के लिए विकल्प निर्माण गलत है या प्रवाह गलत स्थिति में है।

आप ब्राउज़र कंसोल में क्या देखेंगे:

विशिष्ट अर्थ:

• पंजीकरण: आपने एक क्रेडेंशियल बनाने का प्रयास किया जो पहले से मौजूद है (डुप्लिकेट)
• लॉगिन: कम आम; अक्सर इसका मतलब है कि प्रवाह/स्थिति प्लेटफ़ॉर्म के लिए असंगत है

व्यावहारिक संचालन:

• यदि यह मैन्युअल पंजीकरण में होता है, तो इसे "पहले से ही नामांकित" के रूप में मानें और उसी के अनुसार मार्ग करें
• सुनिश्चित करें कि excludeCredentials उपयोगकर्ता के लिए सभी मौजूदा क्रेडेंशियल आईडी को सूचीबद्ध करता है ताकि ऑथेंटिकेटर डुप्लिकेट का पता लगा सके (excludeCredentials देखें)
• सशर्त निर्माण के दौरान, InvalidStateError अपेक्षित है और इसे चुपचाप अनदेखा किया जाना चाहिए: इसका मतलब है कि प्रदाता में एक पासकी पहले से मौजूद है। यही बात सशर्त निर्माण के दौरान NotAllowedError और AbortError पर भी लागू होती है (Chrome पर सशर्त निर्माण देखें)

विशिष्ट अर्थ: ऑथेंटिकेटर आपके अनुरोधित बाधाओं को संतुष्ट नहीं कर सकता है।

सामान्य ट्रिगर:

• डिवाइस स्क्रीन लॉक गायब है (विशेष रूप से Android): प्लेटफ़ॉर्म को बायोमेट्रिक या पिन सत्यापन की आवश्यकता होती है लेकिन डिवाइस में कोई लॉक स्क्रीन कॉन्फ़िगर नहीं है
• बहुत सख्त authenticatorAttachment या निवासी कुंजी धारणाएँ
• उन खंडों में कठिन userVerification आवश्यकताएँ जहाँ वे उपलब्ध नहीं हैं

सुधार: बाधाओं को आराम दें (जहां स्वीकार्य हो) या एक वैकल्पिक मार्ग प्रदान करें। स्क्रीन लॉक न होने के लिए, चुपचाप विफल होने (Android) के बजाय इस स्थिति का पता लगाने और उपयोगकर्ताओं का मार्गदर्शन करने पर विचार करें।

विशिष्ट अर्थ: इनपुट विकृत या असंगत हैं।

सामान्य ट्रिगर:

• एन्कोडिंग गलतियाँ (base64 बनाम base64url)
• अमान्य क्रेडेंशियल आईडी / चुनौती स्वरूपण

सुधार: उस सीमा पर इनपुट को मान्य और सामान्य करें जहां आप WebAuthn विकल्प उत्पन्न करते हैं। व्यवहार में, DataError परिपक्व उत्पादन प्रणालियों में प्रभावी रूप से अनुपस्थित है - यदि आपका विकल्प जनरेशन परीक्षण किया गया है, तो आप इसे डैशबोर्ड में नहीं देखेंगे।

यदि ये त्रुटियां नियंत्रण में हैं, तो अगला प्रश्न कवरेज का है: क्या उपयोगकर्ता विफल हो रहे हैं क्योंकि वातावरण आपकी अपेक्षा के अनुसार WebAuthn नहीं कर सकता है?

NotSupportedError एक कवरेज सिग्नल है, विश्वसनीयता सिग्नल नहीं। इसका आमतौर पर मतलब है कि कोई खंड वह नहीं कर सकता जो आपने पूछा था (OS/ब्राउज़र बहुत पुराना, लापता क्षमता, सुविधा सक्षम नहीं)।

आप ब्राउज़र कंसोल में क्या देखेंगे:

पहले दो वास्तविक NotSupportedError DOMExceptions हैं। TypeError प्रविष्टियां तकनीकी रूप से एक अलग अपवाद प्रकार हैं लेकिन समस्या के एक ही वर्ग का प्रतिनिधित्व करती हैं: ब्राउज़र या वातावरण आपने जो पूछा है उसका समर्थन नहीं करता है। JSON सीरियलाइज़ेशन TypeError परिवार व्यवहार में स्वयं NotSupportedError DOMException की तुलना में कहीं अधिक आम है (नीचे देखें)।

सामान्य कारणों में शामिल हैं:

• पुराने ब्राउज़र/OS संस्करण जो बुनियादी WebAuthn का समर्थन नहीं करते हैं
• उस प्लेटफ़ॉर्म पर उपलब्ध न होने वाली WebAuthn सुविधाओं का अनुरोध करना
• असमर्थित उपकरणों पर प्लेटफ़ॉर्म-विशिष्ट प्रवाह का प्रयास करना

JSON सीरियलाइज़ेशन परिवार उत्पादन में NotSupportedError-श्रेणी की विफलताओं का सबसे बड़ा स्रोत है। तकनीकी रूप से ये TypeError (मिसिंग मेथड) के रूप में सामने आते हैं, न कि DOMException के रूप में, लेकिन यह वह जगह है जहाँ आप उनका सामना करेंगे। दो अलग-अलग मूल कारण:

1. ब्राउज़र WebAuthn JSON सीरियलाइज़ेशन विधियों का समर्थन नहीं करता है। ब्राउज़र में navigator.credentials है लेकिन PublicKeyCredential.parseCreationOptionsFromJSON / parseRequestOptionsFromJSON नहीं है। यह इस त्रुटि परिवार का लगभग 90% हिस्सा है, जो पुराने Safari और Chrome संस्करणों में केंद्रित है। यदि आपकी क्लाइंट लाइब्रेरी बिना फ़ॉलबैक के इन विधियों पर निर्भर करती है, तो यह महत्वपूर्ण त्रुटि मात्रा उत्पन्न करती है।
2. पासवर्ड मैनेजर एक्सटेंशन .toJSON() को तोड़ते हैं। Bitwarden, LastPass, या 1Password जैसे एक्सटेंशन समारोह को बीच में रोक सकते हैं और एक ऑब्जेक्ट वापस कर सकते हैं जो एक क्रेडेंशियल जैसा दिखता है लेकिन एक वास्तविक PublicKeyCredential इंस्टेंस नहीं है। इस पर .toJSON() को कॉल करने से या तो थ्रो होता है, अपरिभाषित लौटता है, या ऑब्जेक्ट पूरी तरह से null होता है। यह परिवार का लगभग 10% है लेकिन डिबग करने के लिए विशेष रूप से भ्रामक है क्योंकि त्रुटि संदेश ब्राउज़र द्वारा भिन्न होते हैं (Safari: "Can only call on instances of PublicKeyCredential"; Firefox: "does not implement interface PublicKeyCredential")।

हैंडलिंग कुंद और तेज़ होनी चाहिए:

• फ़ॉलबैक पासवर्ड/OTP पर तुरंत वापस आएं
• सेगमेंट रिकॉर्ड करें ताकि आप कवरेज गैप को माप सकें
• लगातार विफल होने वाले सेगमेंट पर पासकी CTA दिखाने से बचें

यदि कवरेज ठीक लगता है लेकिन विफलताएं अभी भी विशिष्ट खंडों में होती हैं, तो आप UnknownError के रूप में सामने आने वाले प्लेटफ़ॉर्म-लेयर मुद्दों से निपट सकते हैं।

UnknownError ऑथेंटिकेटर/OS विफलताओं के लिए एक कैच-ऑल है जो अन्य श्रेणियों में सफाई से मैप नहीं करते हैं। यह अक्सर क्षणिक होता है, लेकिन OS अपडेट के बाद भी यह बढ़ सकता है।

आप ब्राउज़र कंसोल में क्या देखेंगे:

व्यावहारिक हैंडलिंग:

• रिट्री-फ्रेंडली UX का उपयोग करें (उपयोगकर्ता को "दोष" न दें)
• जहां संभव हो OS/बिल्ड नंबर और क्रेडेंशियल-मैनेजर/प्रदाता संदर्भ कैप्चर करें
• OS अपडेट के बाद सेगमेंट-विशिष्ट स्पाइक्स पर नज़र रखें

त्रुटियों का एक विशिष्ट स्रोत जो किसी भी DOMException श्रेणी में अच्छी तरह से फिट नहीं होता है: पासवर्ड मैनेजर ब्राउज़र एक्सटेंशन (जैसे Bitwarden, LastPass, 1Password, और अन्य) WebAuthn API कॉल को रोक सकते हैं और गैर-मानक प्रतिक्रियाएं दे सकते हैं। जबकि उपयोगकर्ता रद्दीकरण की तुलना में मात्रा में छोटा है, वे ट्रैक करने लायक हैं क्योंकि वे लगातार विशिष्ट उपयोगकर्ता खंडों को प्रभावित करते हैं और लक्षण भ्रामक होते हैं: लौटे क्रेडेंशियल ऑब्जेक्ट पर लापता विधियां, अप्रत्याशित त्रुटि प्रकार, या विकृत प्रतिक्रियाएं जो किसी भी प्रलेखित WebAuthn त्रुटि से मेल नहीं खाती हैं। ये अक्सर UnknownError या अवर्गीकृत अपवादों के रूप में सामने आते हैं। यदि आप बिना किसी OS-स्तरीय स्पष्टीकरण के विशिष्ट ब्राउज़रों में केंद्रित त्रुटि स्पाइक्स देखते हैं, तो जांचें कि क्या क्रेडेंशियल मैनेजर एक्सटेंशन शामिल है।

अब तक हमने वेब ब्राउज़र त्रुटि नामों को कवर किया है। लेकिन यदि आप नेटिव ऐप भी शिप करते हैं, तो त्रुटि परिदृश्य अलग है - और कुछ मायनों में, काफी बेहतर है।

उपरोक्त सब कुछ वेब ब्राउज़रों को कवर करता है। नेटिव ऐप्स - ASAuthorization फ्रेमवर्क के साथ iOS, Credential Manager के साथ Android - समान मौलिक त्रुटि श्रेणियों को साझा करते हैं लेकिन महत्वपूर्ण तरीकों से भिन्न होते हैं:

1. "कोई क्रेडेंशियल नहीं" एक अलग संकेत है। वेब पर, ब्राउज़र गोपनीयता के लिए "कोई क्रेडेंशियल उपलब्ध नहीं" और "उपयोगकर्ता रद्द" को एक ही NotAllowedError में ढहा देते हैं। नेटिव पर, iOS (ASAuthorizationController) पर preferImmediatelyAvailableCredentials या Android (GetCredentialRequest) पर setPreferImmediatelyAvailableCredentials(true) का उपयोग करने से OS को केवल डिवाइस पर पहले से मौजूद क्रेडेंशियल प्रस्तुत करने और कोई भी मौजूद न होने पर तुरंत विफल होने के लिए कहा जाता है। यह आपको एक साफ "कोई क्रेडेंशियल नहीं" रिटर्न देता है जो वेब प्रदान नहीं कर सकता।

2. क्रेडेंशियल प्रदाता की स्थिति दिखाई दे रही है। कुछ स्थितियों में नेटिव प्लेटफ़ॉर्म आपको बता सकते हैं कि जब कोई क्रेडेंशियल प्रदाता (Google Password Manager, iCloud Keychain, 1Password, आदि) स्थापित, कॉन्फ़िगर, या डिफ़ॉल्ट के रूप में सेट नहीं है और उस पर प्रतिक्रिया करते हैं। वेब पर, यह जानकारी अपारदर्शी NotAllowedError संदेशों के पीछे छिपी होती है।

3. त्रुटि संदेश अधिक विशिष्ट हैं। क्योंकि उपयोगकर्ता ने ऐप इंस्टॉल कर लिया है - और इस तरह रिलाइंग पार्टी के साथ विश्वास संबंध स्थापित कर लिया है - OS अधिक नैदानिक विवरण सामने लाता है। गोपनीयता संबंधी विचार जो वेब ब्राउज़रों को अस्पष्ट होने के लिए मजबूर करते हैं, उसी तरह लागू नहीं होते हैं जब ऐप पहले से ही डिवाइस पर होता है। iOS उपयोगकर्ता की डिवाइस भाषा में स्थानीयकृत संदेश लौटाता है। Android कारण श्रृंखलाओं के साथ संरचित त्रुटि प्रकार देता है। इससे डिबगिंग आसान हो जाती है लेकिन इसका मतलब है कि आपके त्रुटि प्रबंधन को स्थानीयकरण और प्लेटफ़ॉर्म-विशिष्ट त्रुटि प्रारूपों का हिसाब रखना होगा।

iOS ASAuthorization फ्रेमवर्क के माध्यम से पासकी त्रुटियों को सामने लाता है। सभी त्रुटियां authorizationController(controller:didCompleteWithError:) डेलिगेट कॉलबैक में NSError ऑब्जेक्ट के रूप में आती हैं।

डोमेन + कोड द्वारा वर्गीकृत करें, संदेश स्ट्रिंग द्वारा नहीं। प्राथमिक त्रुटि डोमेन com.apple.AuthenticationServices.AuthorizationError (ASAuthorizationError.errorDomain) है। let nsError = error as NSError के साथ त्रुटि को कास्ट करें और .domain और .code पर मिलान करें। उत्पादन में कभी भी .localizedDescription पर मिलान न करें - Apple के संदेशों को 30+ भाषाओं में स्थानीयकृत किया जाता है और OS संस्करणों में बदला जा सकता है। नीचे सूचीबद्ध संदेश स्ट्रिंग लॉग में त्रुटियों को पहचानने के लिए उपयोगी हैं, लेकिन वे वर्गीकरण मानदंड नहीं हैं।

सार्वजनिक ASAuthorizationError कोड:

उत्पादन के लिए सबसे महत्वपूर्ण अंतर: iOS 18 के बाद से, डुप्लिकेट क्रेडेंशियल्स अपना स्वयं का त्रुटि कोड 1006 (MatchedExcludedCredential) लौटाते हैं। iOS 17 और इससे पहले पर, डुप्लिकेट क्रेडेंशियल्स कोड 1004 (Failed) के अंदर छिपे हुए थे। iOS 18+ पर, अंतर संरचनात्मक (अलग त्रुटि कोड) है, टेक्स्टुअल नहीं।

सामान्य रनटाइम त्रुटियां (लॉग-स्तरीय संदर्भ):

ये संदेश विशिष्ट विफलता परिदृश्यों के लिए localizedDescription या userInfo में दिखाई देते हैं। उनका उपयोग लॉग खोज और डिबगिंग के लिए करें, न कि प्रोग्रामेटिक वर्गीकरण के लिए।

स्थानीयकृत "कोई क्रेडेंशियल नहीं" संदेश (कोड 1005):

जब preferImmediatelyAvailableCredentials सेट किया जाता है और कोई पासकी मौजूद नहीं होती है, तो iOS उपयोगकर्ता की डिवाइस भाषा में स्थानीयकृत संदेश के साथ कोड 1005 (NotInteractive) लौटाता है। यह नेटिव ऐप्स के लिए अद्वितीय है - वेब ब्राउज़र इस संकेत को कभी उजागर नहीं करते हैं। संदेश हमेशा The operation couldn't be completed. के साथ शुरू होता है, जिसके बाद स्थानीयकृत टेक्स्ट होता है:

अंग्रेजी-लोकेल डिवाइस आमतौर पर API स्तर पर "कोई क्रेडेंशियल नहीं" का समाधान करते हैं, इससे पहले कि ASAuthorization ढांचा स्थानीयकृत त्रुटि लौटाए, यही वजह है कि ऊपर कोई अंग्रेजी संस्करण दिखाई नहीं देता है। प्रोग्रामेटिक रूप से, इन स्ट्रिंग्स को पार्स करने के बजाय हमेशा कोड 1005 पर मिलान करें।

Android Credential Manager API (androidx.credentials) के माध्यम से पासकी त्रुटियों को सामने लाता है। त्रुटि संदेशों में एक प्राथमिक संदेश और अक्सर अतिरिक्त विवरण के साथ एक cause शामिल होता है। iOS की तुलना में, Android कॉन्फ़िगरेशन मुद्दों के लिए अधिक संरचित त्रुटि प्रकार और अधिक स्पष्ट कारण प्रदान करता है।

उपयोगकर्ता रद्दीकरण और क्रेडेंशियल पहचान:

कॉन्फ़िगरेशन और सुरक्षा त्रुटियां:

प्लेटफ़ॉर्म और ऑथेंटिकेटर त्रुटियां:

निम्नलिखित आरेख दिखाता है कि ऊपर चर्चा की गई सभी परतें - इन्फ्रास्ट्रक्चर, पर्यावरण, ऑपरेशन प्रकार, वर्गीकरण और डिटेक्शन - एक छोर से दूसरे छोर तक कैसे जुड़ते हैं। यह वह मानसिक मॉडल है जिसे आपको अपनी त्रुटि ट्रैकिंग डिज़ाइन करते समय ध्यान में रखना चाहिए।

flowchart TD
    %% Global Styles
    classDef expected fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
    classDef unexpected fill:#ffebee,stroke:#c62828,stroke-width:2px;
    classDef network fill:#fff3e0,stroke:#ef6c00,stroke-dasharray: 5 5;
    classDef env fill:#f3e5f5,stroke:#7b1fa2,stroke-width:1px;
    classDef action fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;

    %% --- LEFT SIDE: NETWORK & SERVER ---
    subgraph Infrastructure ["इन्फ्रास्ट्रक्चर (सर्वर/नेटवर्क)"]
        direction TB
        ServerErr["सर्वर साइड त्रुटि<br/>500 / लॉजिक त्रुटि"]:::network
        NetErr["नेटवर्क त्रुटि<br/>टाइमआउट / 400 खराब अनुरोध"]:::network

        ServerErr & NetErr -->|के रूप में प्रकट होता है| ClientManifest["क्लाइंट-साइड सामान्य त्रुटि"]
    end

    %% --- CENTER: THE ENVIRONMENT STACK (From Sketch) ---
    subgraph Environment ["पर्यावरण (क्लाइंट साइड)"]
        direction TB

        %% Layer 1: Platform Type
        subgraph Type ["परत 1: प्लेटफ़ॉर्म"]
            Web["वेब / ब्राउज़र"]
            Native["नेटिव / ऐप"]
        end

        %% Layer 2: OS Context
        subgraph OS_Layer ["परत 2: OS और संस्करण"]
            OS_Web["OS: Windows, macOS, Linux"]
            OS_Nat["OS: iOS, Android"]
            OS_Ver["OS संस्करण / सेटिंग्स<br/>(स्क्रीन लॉक, बायोमेट्रिक्स)"]

            Web --> OS_Web
            Native --> OS_Nat
            OS_Web & OS_Nat --> OS_Ver
        end

        %% Layer 3: Client Software
        subgraph Client_Layer ["परत 3: क्लाइंट सॉफ़्टवेयर"]
            Browser["ब्राउज़र: Chrome, Safari, Edge<br/>+ संस्करण"]
            App["नेटिव ऐप / वेबव्यू<br/>+ ऐप संस्करण"]

            OS_Ver --> Browser
            OS_Ver --> App
        end

        %% Layer 4: WebAuthn Operation
        subgraph Op_Layer ["परत 4: WebAuthn ऑपरेशन"]
            OpType{"ऑपरेशन प्रकार"}

            Login["लॉगिन<br/>(navigator.credentials.get)"]
            Reg["पंजीकरण<br/>(navigator.credentials.create)"]

            Browser & App --> OpType
            OpType --> Login
            OpType --> Reg
        end

        %% Layer 5: Sub-types & Complexity
        subgraph Modality ["परत 5: तौर-तरीके और जटिलता"]
            Sub_CUI["CUI / सशर्त UI"]
            Sub_Auto["स्वचालित संचालन"]
            Sub_CDA["CDA / क्रॉस-डिवाइस ऑथ"]

            Login & Reg --> Sub_CUI
            Login & Reg --> Sub_Auto
            Login & Reg --> Sub_CDA
        end
    end

    %% --- BOTTOM: CLASSIFICATION & ACTION (The "What here?" section) ---
    subgraph Analysis ["त्रुटि विश्लेषण और रनटाइम"]
        direction TB

        %% Classification
        Classification{"वर्गीकरण"}

        Exp["अपेक्षित त्रुटि<br/>(उपयोगकर्ता ने समारोह रद्द कर दिया)"]:::expected
        Unexp["अप्रत्याशित त्रुटि<br/>(सिस्टम/क्रैश/अज्ञात)"]:::unexpected

        ClientManifest --> Classification
        Sub_CUI & Sub_Auto & Sub_CDA --> Classification

        Classification --> Exp
        Classification --> Unexp

        %% Detection Logic
        subgraph Detection ["डिटेक्शन लक्ष्य"]
            P1["P1: लॉगिन समस्याएँ"]
            P2["P2: निर्माण समस्याएँ"]
            Baseline["बेसलाइन ड्रिफ्ट का पता लगाएं<br/>(बढ़ा हुआ अपेक्षित)"]
            NewErr["नई विसंगतियों का पता लगाएं<br/>(बढ़ा हुआ अप्रत्याशित)"]
        end

        Exp --> Baseline
        Unexp --> NewErr
        Exp & Unexp --> P1 & P2

        %% Actionable Outcomes
        subgraph Action ["शमन कार्रवाई"]
            Fix["हॉटफिक्स तैनात करें / नया संस्करण"]:::action
            Fallback["स्वचालित फ़ॉलबैक सक्रिय करें<br/>(पासकी अक्षम करें)"]:::action
        end

        P1 & P2 & NewErr --> Fix
        P1 & P2 & NewErr --> Fallback
    end

    %% Connectors
    Infrastructure -.-> Environment

मुख्य अंतर्दृष्टि: एक कच्चा error.name केवल तभी समझ में आता है जब आप जानते हैं कि पर्यावरण की किस परत ने इसे उत्पन्न किया, कौन सा ऑपरेशन चल रहा था और क्या त्रुटि अपेक्षित थी या अप्रत्याशित थी। नीचे दिए गए अनुभाग शामिल करते हैं कि क्या लॉग करना है और उस पर कैसे कार्य करना है।

इस लेख में अधिकांश त्रुटि वर्गीकरण अकेले क्लाइंट-साइड संकेतों के साथ किया जा सकता है। एक फ्रंटएंड-ओनली ऑब्ज़र्वेबिलिटी SDK अधिकांश WebAuthn त्रुटियों को वर्गीकृत करने के लिए पर्याप्त संदर्भ कैप्चर करता है। इसी तरह Corbado का ऑब्ज़र्वेबिलिटी SDK भी आर्किटेक्ट किया गया है: क्लाइंट-साइड लेयर त्रुटि एट्रिब्यूशन, समय, ऑपरेशन संदर्भ और प्लेटफ़ॉर्म डिटेक्शन को संभालती है। सर्वर-साइड लॉगिंग उन विफलताओं के लिए एक दूसरी परत जोड़ता है जिन्हें केवल बैकएंड ही देख सकता है।

मुख्य आवश्यकता: हर प्रयास को एंड-टू-एंड जुड़ने योग्य होना चाहिए। एक साझा सहसंबंध आईडी (उदा. auth_flow_id) क्लाइंट-साइड संदर्भ को सर्वर सत्यापन परिणाम से जोड़ता है।

ब्राउज़र द्वारा एक क्रेडेंशियल और हस्ताक्षरित चुनौती लौटाए जाने के बाद सर्वर सत्यापन विफलताएं होती हैं। ये स्पष्ट कोड के साथ संरचित त्रुटियां होनी चाहिए, न कि क्लाइंट-साइड DOMException नामों के समान बकेट में मिश्रित। WebAuthn सर्वर कार्यान्वयन देखें।

यदि आप एक पूर्ण फ़नल मॉडल (चरण और चरणों के बीच रूपांतरण द्वारा ड्रॉप-ऑफ़) चाहते हैं, तो ड्रॉप-ऑफ़ को समझने के लिए पासकी टेलीमेट्री देखें।

Latest news के लिए हमारे Passkeys Substack को subscribe करें.

Subscribe करें

इस डेटा के साथ, निष्कर्ष सरल हो जाता है: अधिकांश "त्रुटियां" या तो UX फिक्स, कवरेज फिक्स, या कॉन्फ़िगरेशन फिक्स बन जाती हैं। लेकिन इस वर्गीकरण को स्वयं बनाना और बनाए रखना महत्वपूर्ण चल रहा काम है।

ऊपर दी गई लॉगिंग चेकलिस्ट कच्चे संकेतों को कैप्चर करती है। बड़े पैमाने पर उत्पादन में, अकेले error.name पर्याप्त नहीं है। इस वर्गीकरण को स्वयं बनाना महत्वपूर्ण चल रहा काम है: त्रुटि संदेश हर ब्राउज़र और OS रिलीज़ के साथ बदलते हैं, पासवर्ड मैनेजर प्रदाता ऐसे अपडेट शिप करते हैं जो समारोह के व्यवहार को बदलते हैं और हर फीचर लॉन्च के साथ नए त्रुटि हस्ताक्षर दिखाई देते हैं।

एक ही NotAllowedError का मतलब छह अलग-अलग चीजें हो सकती हैं जो तीन आयामों पर निर्भर करती हैं जिन्हें ब्राउज़र आपके लिए अलग नहीं करते हैं:

यही वह समस्या है जिसे हल करने के लिए Corbado का ऑब्ज़र्वेबिलिटी SDK बनाया गया है। यह एक हल्का फ्रंटएंड एकीकरण है जो आपके मौजूदा पासकी कार्यान्वयन के शीर्ष पर बैठता है, किसी भी WebAuthn सर्वर और किसी भी IDP के साथ काम करता है, और स्वचालित रूप से सभी तीन आयामों के साथ हर WebAuthn त्रुटि को वर्गीकृत करता है:

यह ऑब्ज़र्व लेयर है: आपके कार्यान्वयन को बदले बिना, क्या हो रहा है इसकी दृश्यता।

Corbado का प्रबंधन कंसोल दो जांच पथों का समर्थन करता है:

टॉप-डाउन (डैशबोर्ड से मूल कारण तक):

1. दो अलग-अलग विसंगति प्रकारों के लिए मॉनिटर करें:
   • बढ़ी हुई अपेक्षित त्रुटियां (बेसलाइन ड्रिफ्ट): क्या किसी विशिष्ट वातावरण (उदा., iPhone 15 पर iOS 18.2) में "उपयोगकर्ता कैंसल" में क्रमिक वृद्धि देखी गई है? यह अक्सर OS अपडेट द्वारा पेश किए गए UX घर्षण को इंगित करता है।
   • बढ़ी हुई अप्रत्याशित त्रुटियां (स्पाइक्स): एक पूरी तरह से नई त्रुटि या विफलताओं में अचानक उछाल। यह आमतौर पर एक ब्रेकिंग चेंज (आंतरिक IDP स्टैक अपडेट) या एक नए ब्राउज़र संस्करण में प्रतिगमन को इंगित करता है।
2. प्रभाव के आधार पर प्राथमिकता दें:
   • P1: लॉगिन समस्याएँ। यदि लॉगिन सफलता दर गिरती है, तो तुरंत अलर्ट करें।
   • P2: निर्माण समस्याएँ। प्रवृत्तियों की निगरानी करें, लेकिन निर्माण प्रवाह में "उपयोगकर्ता कैंसल" स्पाइक्स के लिए इंजीनियरों को जगाने से बचें।
3. पर्यावरण में ड्रिल करें: यह अलग करने के लिए दानेदार आयामों (हार्डवेयर, ऑथ सेटिंग्स) का उपयोग करें कि क्या समस्या वैश्विक है या "Android 14 वाले Samsung उपकरणों" के लिए विशिष्ट है।
4. शमन: यदि किसी महत्वपूर्ण स्पाइक का पता चलता है, तो एक किल स्विच तैयार रखें। जांच करते समय लॉगिन दरों को संरक्षित करने के लिए उस विशिष्ट वातावरण के लिए पासकी को स्वचालित रूप से या मैन्युअल रूप से अक्षम करें और OTP/पासवर्ड पर वापस आएं।

बॉटम-अप (त्रुटि पैटर्न से प्रभाव तक):

1. त्रुटि वर्गीकरण दृश्य से प्रारंभ करें। वर्गीकृत त्रुटि पैटर्न और उनके संस्करणों की समीक्षा करें।
2. जैसे-जैसे नए पैटर्न उभरते हैं, त्रुटि मैपिंग को परिष्कृत करें (उदा. एक नया ब्राउज़र संस्करण एक अलग त्रुटि संदेश शिपिंग कर रहा है)।
3. त्रुटियों को KPI परिवर्तनों के साथ क्रॉस-सहसंबंधित किया जाता है और डैशबोर्ड पर एनोटेशन के रूप में सामने लाया जाता है, इसलिए एक विशिष्ट त्रुटि पैटर्न में स्पाइक स्वचालित रूप से उस मीट्रिक से जुड़ा होता है जिसे उसने प्रभावित किया था।

दोनों पथ अभिसरण करते हैं: टॉप-डाउन आपको बताता है कि कुछ गलत है, बॉटम-अप आपको बताता है कि क्यों। AI Analytics Assistant त्रुटि डेटा और अपनाने के मेट्रिक्स दोनों में आपको प्राकृतिक भाषा में प्रश्न पूछने की अनुमति देकर दोनों को जोड़ता है।

जो टीमें इन संकेतों पर कार्य करना चाहती हैं, वे एडॉप्ट में जा सकती हैं, जो स्वचालित रूप से समारोहों को गेट करने, नामांकन प्रॉम्प्ट को अनुकूलित करने और टूटी हुई पासकी स्थितियों को ठीक करने के लिए पासकी इंटेलिजेंस जोड़ता है। विनियमित वातावरण या हाइपरस्केल तैनाती के लिए, एंटरप्राइज़ सिंगल-टेनेंट होस्टिंग, SIEM एकीकरण और PSD2-अनुपालन कॉन्फ़िगरेशन जोड़ता है।

Enterprises के लिए मुफ्त passkey whitepaper पाएं.

मुफ्त पाएं

WebAuthn त्रुटि नाम एक फैसला नहीं हैं। वे संकेत हैं - और वे केवल तभी कार्रवाई योग्य हो जाते हैं जब आप उन्हें ऑपरेशन प्रकार, समय और प्लेटफ़ॉर्म संदर्भ से जोड़ते हैं।

• उत्पादन में सबसे आम WebAuthn त्रुटि नामों का क्या अर्थ है? अधिकांश परतों के एक छोटे सेट पर मैप करते हैं: उपयोगकर्ता नियंत्रण प्रवाह (NotAllowedError), ऐप जीवनचक्र/समवर्ती (AbortError), सुरक्षा संदर्भ/कॉन्फ़िगरेशन (SecurityError), या विकल्प/स्थिति बग (InvalidStateError, ConstraintError, DataError)। अधिकांश मात्रा NotAllowedError है, और इसमें से अधिकांश अपेक्षित व्यवहार (उपयोगकर्ता ने प्रॉम्प्ट को खारिज कर दिया) है।
• आप NotAllowedError को कैसे अस्पष्ट करते हैं? समय (तत्काल अस्वीकृति बनाम उपयोगकर्ता कैंसल बनाम टाइमआउट), एक QR/हाइब्रिड संकेतक (उपलब्धता बेमेल), उपयोगकर्ता-सक्रियण संदर्भ (विशेष रूप से iOS/Safari पर) और ऑपरेशन प्रकार (सशर्त UI बनाम मोडल लॉगिन बनाम पासकी निर्माण बनाम सशर्त निर्माण) का उपयोग करें। सभी NotAllowedError को एक विफलता मोड के रूप में न मानें।
• ऑपरेशन का प्रकार क्यों मायने रखता है? सशर्त UI लॉगिन के दौरान समान error.name सशर्त निर्माण या मैन्युअल पासकी निर्माण (उपयोगकर्ता ने संवाद खारिज कर दिया) की तुलना में पूरी तरह से अलग संकेत है। त्रुटि के साथ ऑपरेशन प्रकार को लॉग करना ही सामान्य NotAllowedError को एक कार्रवाई योग्य बकेट में बदल देता है।
• कौन सा न्यूनतम संदर्भ त्रुटियों को डीबग करने योग्य बनाता है? error.name, ऑपरेशन प्रकार, ऑपरेशन शुरू होने से त्रुटि तक का समय, प्रवाह प्रकार, क्या QR/हाइब्रिड UI दिखाया गया था, OS/ब्राउज़र/डिवाइस (संस्करणों सहित), एक सहसंबंध आईडी (auth_flow_id) और सर्वर सत्यापन अस्वीकृतियों को स्पष्ट कोड के रूप में कैप्चर करें।

विफलता के सभी प्रकारों को काटने वाले थंब रूल: कभी भी उपयोगकर्ताओं को कच्चे ब्राउज़र त्रुटियां न दिखाएं - हमेशा एक स्पष्ट फ़ॉलबैक पथ प्रदान करें - और स्थानीय प्रयासों को QR/हाइब्रिड क्रॉस-डिवाइस प्रयासों से अलग करें, क्योंकि वे अलग-अलग कारणों से विफल होते हैं और अलग-अलग फिक्स की आवश्यकता होती है। पैमाने पर, ब्राउज़रों, OS संस्करणों और क्रेडेंशियल प्रबंधकों में त्रुटि वर्गीकरण बनाए रखना चल रहा काम है। इसे खरोंच से बनाने के बजाय एक अनुरक्षित पैटर्न लाइब्रेरी के साथ एक ऑब्ज़र्वेबिलिटी SDK का उपयोग करने पर विचार करें।

Corbado के बारे में

Corbado बड़े पैमाने पर consumer authentication चलाने वाली CIAM टीमों के लिए Authentication Intelligence Platform है। हम आपको वह दिखाते हैं जो IDP logs और सामान्य analytics tools नहीं दिखा सकते: कौन-से devices, OS versions, browsers और credential managers passkeys को support करते हैं, क्यों enrollments login में नहीं बदलते, WebAuthn flow कहाँ fail होता है, और कब कोई OS या browser update चुपचाप login को तोड़ देता है — और यह सब Okta, Auth0, Ping, Cognito या आपके in-house IDP को बदले बिना। दो products: Corbado Observe जोड़ता है passkeys और किसी भी अन्य login method के लिए observability। Corbado Connect देता है analytics के साथ built-in managed passkeys (आपके IDP के साथ-साथ)। VicRoads, Corbado के साथ 5M+ users के लिए passkeys चला रहा है (+80% passkey activation)। Passkey विशेषज्ञ से बात करें →

वेब पर, ब्राउज़र गोपनीयता कारणों से दोनों मामलों को NotAllowedError में ढहा देते हैं, इसलिए आप उन्हें सीधे अलग नहीं कर सकते। एक प्रॉक्सी के रूप में समय का उपयोग करें: 1 सेकंड से कम की त्रुटि का आमतौर पर मतलब पर्यावरण अस्वीकृति या लापता क्षमता होता है, जबकि 1-15 सेकंड बताता है कि उपयोगकर्ता ने संवाद देखा और खारिज कर दिया। नेटिव iOS और Android ऐप पर, अनुरोध से पहले preferImmediatelyAvailableCredentials सेट करने से आपको कोई भी UI दिखाए जाने से पहले एक साफ "कोई क्रेडेंशियल नहीं" संकेत (iOS कोड 1005, Android GetCredentialRequest) मिलता है।

अनुकूलित बड़े पैमाने पर पासकी तैनाती में, दर्ज की गई 95% से अधिक WebAuthn त्रुटियां अपेक्षित उपयोगकर्ता गर्भपात हैं, सिस्टम विफलताएं नहीं हैं। "उपयोगकर्ता ने प्रॉम्प्ट खारिज कर दिया" को वास्तविक विफलताओं से अलग किए बिना कच्चे error.name की गिनती ट्रैक करने से त्रुटि मेट्रिक्स बढ़ जाते हैं और NotAllowedError वॉल्यूम के अंदर छिपे वास्तविक प्रतिगमन को मुखौटा बना देते हैं। अपनी गणनाओं को ऑपरेशन प्रकार से विभाजित करें और उपयोगकर्ता-कैंसल बकेट को SecurityError, ConstraintError और DataError जैसी अप्रत्याशित त्रुटियों से अलग से मानें।

iOS कोड 1005 (NotInteractive) का अर्थ है कि डिवाइस पर कोई पासकी उपलब्ध नहीं थी जब ASAuthorizationController पर preferImmediatelyAvailableCredentials सेट किया गया था, और उपयोगकर्ता को कोई UI नहीं दिखाया गया था। यह साफ़ "इस डिवाइस पर कोई पासकी मौजूद नहीं है" संकेत है जो वेब ब्राउज़र गोपनीयता बाधाओं के कारण प्रदान नहीं कर सकते हैं। हमेशा संख्यात्मक कोड पर वर्गीकृत करें, localizedDescription पर नहीं, क्योंकि Apple के संदेशों को 30+ भाषाओं में स्थानीयकृत किया जाता है और OS संस्करणों में बदला जा सकता है।

सशर्त निर्माण के दौरान, NotAllowedError, AbortError और InvalidStateError सभी अपेक्षित परिणाम हैं और इन्हें त्रुटियों के रूप में सामने लाने के बजाय चुपचाप अनदेखा किया जाना चाहिए। NotAllowedError इंगित करता है कि ऑटोफिल अनुपलब्ध है या पृष्ठ ने फोकस खो दिया है, जबकि InvalidStateError का अर्थ है कि प्रदाता में एक पासकी पहले से मौजूद है। कॉल का प्रयास करने से पहले, conditionalCreate समर्थन को सत्यापित करने के लिए getClientCapabilities() का उपयोग करें और अपनी त्रुटि गणनाओं को बढ़ाने से बचने के लिए दस्तावेज़ दृश्यता स्थिति की जांच करें।

ऑपरेशन प्रकार (सशर्त UI, मोडल लॉगिन, मैन्युअल निर्माण, सशर्त निर्माण या ऑटो-अपेंड), ऑपरेशन शुरू होने से त्रुटि तक का समय, OS संस्करण, ब्राउज़र संस्करण, हार्डवेयर मॉडल, क्या QR/हाइब्रिड UI दिखाई दिया और सर्वर-साइड लॉग के साथ जुड़ने के लिए एक सहसंबंध आईडी कैप्चर करें। चुनौती बेमेल, अमान्य हस्ताक्षर और क्रेडेंशियल न मिलने जैसी सर्वर सत्यापन विफलताओं को स्पष्ट संरचित कोड के रूप में लॉग किया जाना चाहिए, न कि क्लाइंट-साइड DOMException नामों के समान बकेट में मिश्रित किया जाना चाहिए। ये संकेत एक साथ बिना अनुमान लगाए कार्रवाई योग्य बकेट में अधिकांश त्रुटियों के वर्गीकरण की अनुमति देते हैं।