--- url: 'https://www.corbado.com/hi/blog/webauthn-errors' title: 'अल्टीमेट WebAuthn एरर इन प्रोडक्शन गाइड (2026)' description: 'जानें कि उत्पादन में NotAllowedError जैसी सामान्य WebAuthn त्रुटियों का क्या अर्थ है और उन्हें ऑपरेशन प्रकार, समय और प्लेटफ़ॉर्म संदर्भ के आधार पर कैसे वर्गीकृत किया जाए।' lang: 'hi' author: 'Vincent Delitz' date: '2026-07-03T07:10:15.697Z' lastModified: '2026-07-03T07:10:43.560Z' keywords: 'webauthn त्रुटियाँ, NotAllowedError, AbortError, SecurityError, WebAuthn समस्या निवारण, पासकी त्रुटि वर्गीकरण, सशर्त निर्माण त्रुटियाँ, ASAuthorizationError, ASAuthorizationError कोड, androidx.credentials, क्रेडेंशियल मैनेजर पासकी त्रुटियाँ, iOS' category: 'WebAuthn Know-How' --- # अल्टीमेट WebAuthn एरर इन प्रोडक्शन गाइड (2026) ## 1. परिचय उत्पादन (production) में, WebAuthn त्रुटियाँ भ्रमित करने वाली होती हैं क्योंकि ब्राउज़र `DOMException` नामों का एक छोटा सा सेट (जैसे `NotAllowedError`) उजागर करते हैं जो कई अंतर्निहित कारणों का प्रतिनिधित्व कर सकते हैं। इसके अलावा, अधिकांश "त्रुटियाँ" - अनुकूलित बड़े पैमाने की तैनाती में अक्सर 95% से ऊपर - वास्तव में **अपेक्षित व्यवहार** (उपयोगकर्ता ने ऑपरेटिंग सिस्टम पासकी (passkey) प्रॉम्प्ट को रद्द कर दिया) होती हैं। > महत्वपूर्ण: गोपनीयता कारणों से, ब्राउज़र यह अंतर नहीं करते हैं कि उपयोगकर्ता ने सक्रिय रूप से रद्द किया है या कोई पासकी मौजूद नहीं थी। हालाँकि, कुछ स्थितियों में और पर्याप्त संदर्भ के साथ, वेब और नेटिव प्लेटफ़ॉर्म दोनों पर, इनमें से कुछ मामलों को समय (timing) जैसे संकेतों का उपयोग करके अलग किया जा सकता है। यदि आप इन नामों के लिए विहित परिभाषाएँ चाहते हैं, तो [MDN `DOMException`](https://developer.mozilla.org/en-US/docs/Web/API/DOMException) से प्रारंभ करें। WebAuthn-विशिष्ट स्थितियों के लिए जो इन अपवादों को जन्म देती हैं (और ब्राउज़र को क्या लागू करना आवश्यक है), [W3C Web Authentication spec](https://www.w3.org/TR/webauthn-3/) देखें। यदि आप सभी त्रुटियों को "बग" के रूप में मानते हैं, तो आप गलत काम करेंगे: - आप सामान्य कैंसल के साथ अपने त्रुटि मेट्रिक्स को प्रदूषित करेंगे - आप `NotAllowedError` के ढेर के अंदर छिपे वास्तविक प्रतिगमन को याद करेंगे - आप ऐसा UI शिप करेंगे जो उपयोगकर्ताओं को पुनर्प्राप्त करने में मदद करने के बजाय उन्हें भ्रमित करता है इस लेख में हम उत्तर देते हैं: - वास्तविक ट्रैफ़िक में सबसे सामान्य WebAuthn त्रुटि नामों का आमतौर पर क्या अर्थ होता है? - आप `NotAllowedError` को कार्रवाई योग्य बकेट (कैंसल बनाम टाइमआउट बनाम उपलब्धता) में कैसे अलग करते हैं? - एक ही त्रुटि का ऑपरेशन (सशर्त UI लॉगिन बनाम मोडल लॉगिन बनाम पासकी निर्माण बनाम सशर्त निर्माण) के आधार पर अलग-अलग अर्थ क्यों होता है? - आपको कौन सा न्यूनतम संदर्भ कैप्चर करना चाहिए ताकि "यह विफल रहा" एक पुनरुत्पादनीय समस्या बन जाए? ## Key Facts - `NotAllowedError` एक **सतही संकेत** है, कोई मूल कारण नहीं। संदर्भ के आधार पर इसका अर्थ कैंसल, टाइमआउट, "कोई स्थानीय क्रेडेंशियल नहीं", या उपयोगकर्ता सक्रियता का न होना हो सकता है। - **ऑपरेशन का प्रकार अर्थ बदल देता है।** सशर्त UI लॉगिन, मोडल लॉगिन, मैन्युअल पासकी निर्माण, सशर्त निर्माण और ऑटो-ट्रिगर अपेंड के दौरान समान `NotAllowedError` का अर्थ अलग-अलग होता है। - **ऑपरेशन की शुरुआत से समय** सबसे कम आंका गया संकेत है: तत्काल (`<1s`), उपयोगकर्ता-कैंसल (1-15s) और टाइमआउट (30s+) मौलिक रूप से भिन्न श्रेणियां हैं। - `AbortError` आमतौर पर एक जीवनचक्र/समवर्ती समस्या है (नेविगेशन, री-रेंडर, कई इन-फ़्लाइट अनुरोध)। - `SecurityError` लगभग हमेशा कॉन्फ़िगरेशन/संदर्भ है और परिपक्व उत्पादन परिनियोजन में दुर्लभ है। - "ब्राउज़र त्रुटि नाम" और "सर्वर सत्यापन अस्वीकृति" अलग-अलग परतें हैं। सर्वर अस्वीकृतियों को स्पष्ट कोड के रूप में ट्रैक करें, न कि सामान्य क्लाइंट विफलताओं के रूप में। - **कच्चे त्रुटि नाम अकेले कार्रवाई योग्य नहीं हैं।** हमेशा `error.name` के साथ ऑपरेशन का प्रकार, समय और प्लेटफ़ॉर्म संदर्भ कैप्चर करें ताकि आप त्रुटियों को उन बकेट में वर्गीकृत कर सकें जिन्हें आप वास्तव में ठीक कर सकते हैं। - **"वातावरण" केवल ब्राउज़र + OS से कहीं अधिक है।** त्रुटियों को वास्तव में समझने के लिए, आपको संपूर्ण संयोजन को ट्रैक करने की आवश्यकता है: OS संस्करण, क्लाइंट (ब्राउज़र/ऐप संस्करण), ऑथेंटिकेटर सेटिंग्स (उदा. iCloud/GPM स्थिति) और विशिष्ट हार्डवेयर मॉडल। - **लॉगिन विफलताएं P1 हैं, निर्माण विफलताएं P2 हैं।** जबकि उपयोगकर्ता के छोड़ने के कारण निर्माण त्रुटियां (P2) अक्सर अधिक मात्रा में होती हैं, लॉगिन त्रुटियां (P1) पहुंच को अवरुद्ध करती हैं और तत्काल अलर्टिंग की आवश्यकता होती है। ## 2. एक उत्पादन चीट शीट यदि आपको डीबगिंग को अनब्लॉक करने के लिए केवल एक त्वरित मैपिंग की आवश्यकता है, तो इस तालिका से प्रारंभ करें। यह इस बात की ओर पक्षपाती है कि टीमें वास्तव में डैशबोर्ड और सपोर्ट टिकटों में क्या देखती हैं। | **`error.name`** | **उत्पादन में इसका आमतौर पर क्या अर्थ होता है** | **पुष्टि करने के लिए क्या जाँचें** | **पहली कार्रवाई (UX + इंजीनियरिंग)** | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | `NotAllowedError` | उपयोगकर्ता ने शीट को खारिज कर दिया, टाइम आउट हो गया, या उपलब्धता बेमेल एक बकेट में ढह गई। उत्पादन में यह सबसे बड़ा त्रुटि बकेट है। | त्रुटि का समय, क्या QR/हाइब्रिड UI दिखाई दिया, क्या समारोह एक वास्तविक उपयोगकर्ता कार्रवाई से शुरू हुआ | अपेक्षित रूप में व्यवहार करें: UI पुनर्स्थापित करें + फ़ॉलबैक दिखाएं | | `AbortError` | आपके ऐप (या ब्राउज़र) ने समारोह को निरस्त कर दिया | समारोह के दौरान नेविगेशन/री-रेंडर; समवर्ती WebAuthn कॉल; `AbortController.abort()` | एक इन-फ़्लाइट अनुरोध लागू करें; मार्ग परिवर्तन रोकें; गर्भपात को सामान्य नियंत्रण प्रवाह के रूप में संभालें | | `SecurityError` | संदर्भ/नीति की अनुमति नहीं है | उत्पत्ति + RP ID रणनीति; iframe/एम्बेडिंग; HTTPS; फीचर नीति | RP ID/उत्पत्ति कॉन्फ़िगरेशन ठीक करें; एम्बेडिंग नीतियों को मान्य करें; सुरक्षित संदर्भ सुनिश्चित करें | | `InvalidStateError` | स्थिति बेमेल (अक्सर डुप्लिकेट पंजीकरण) | पंजीकरण बनाम लॉगिन; `excludeCredentials`; ऑथेंटिकेटर पर मौजूदा क्रेडेंशियल | "पहले से ही नामांकित" के रूप में व्यवहार करें; UX पथ समायोजित करें; विकल्प निर्माण को ठीक करें | | `ConstraintError` | आवश्यकताएँ पूरी नहीं की जा सकतीं | `authenticatorAttachment`, `userVerification`, निवासी कुंजी आवश्यकताएँ | बाधाओं को आराम दें या वैकल्पिक मार्ग/फ़ॉलबैक प्रदान करें। उदाहरण: Android पर स्क्रीन लॉक गायब है | | `DataError` | इनपुट विकृत/असंगत हैं | base64url एन्कोडिंग; आईडी/चुनौती/उपयोगकर्ता हैंडल प्रारूप | एन्कोडिंग/सीरियलाइजेशन को ठीक करें; विकल्प निर्माण में सत्यापन जोड़ें | | `NotSupportedError` | प्लेटफ़ॉर्म/ब्राउज़र आपने जो पूछा उसका समर्थन नहीं करता है | OS/ब्राउज़र संस्करण; सुविधा का पता लगाने की धारणाएँ | तुरंत वापस आएँ; खंड रिकॉर्ड करें; असमर्थित वातावरण के लिए पासकी CTA दिखाने से बचें | | `UnknownError` | प्लेटफ़ॉर्म/ऑथेंटिकेटर सामान्य तरीके से विफल रहा | OS अपडेट के बाद स्पाइक्स; डिवाइस निर्माण; क्रेडेंशियल-मैनेजर प्रदाता की समस्याएं | पुनः प्रयास-अनुकूल UX; बिल्ड नंबर कैप्चर करें; सेगमेंट स्पाइक्स की जांच करें | एक चीज जिसे याद करना आसान है: एक ही `error.name` का **ऑपरेशन प्रकार** के आधार पर बहुत अलग अर्थ हो सकता है। नीचे दिए गए अनुभागों को पढ़ते समय ऑपरेशन संदर्भ को ध्यान में रखें। व्यवहार में, पासकी निर्माण (पंजीकरण) त्रुटियां आमतौर पर बड़े अंतर से लॉगिन त्रुटियों से अधिक होती हैं - उपरोक्त तालिका दोनों पर लागू होती है, लेकिन निर्माण वह जगह है जहां अधिकांश मात्रा रहती है। आगे, हम `NotAllowedError` पर गहराई से जाएंगे क्योंकि यह वह है जिसे आप सबसे ज्यादा देखेंगे और जिसे टीमें सबसे अधिक बार गलत समझती हैं। ## 3. NotAllowedError: ऑपरेशन या तो टाइम आउट हो गया या अनुमति नहीं दी गई `NotAllowedError` अक्सर "पासकी विफल" जैसा दिखता है, लेकिन यह आमतौर पर प्लेटफ़ॉर्म आपको यह बता रहा होता है कि उपयोगकर्ता ने OS UI को पूरा नहीं किया। मुख्य बात यह है कि इसे उन बकेट में विभाजित किया जाए जिन पर आप कार्रवाई कर सकते हैं। **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Chrome, Edge | `NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations-client.` | | Safari, WebKit | `NotAllowedError: The request is not allowed by the user agent or the platform in the current context, possibly because the user denied permission.` | | Safari, WebKit | `NotAllowedError: This request has been cancelled by the user.` | | Chrome, Edge | `NotAllowedError: The operation is not allowed at this time because the page does not have focus.` | | Safari, WebKit | `NotAllowedError: The document is not focused.` | | Firefox | `NotAllowedError: Operation failed.` | ये सभी `error.name === "NotAllowedError"` के रूप में सामने आते हैं। `error.message` ब्राउज़र इंजन और अंतर्निहित कारण के अनुसार भिन्न होता है, लेकिन परिणाम समान होता है: समारोह पूरा नहीं हुआ। यह **लॉगिन और पासकी निर्माण दोनों** पर लागू होता है। लॉगिन (सशर्त UI, अनुमति सूची के साथ या उसके बिना मोडल) के दौरान, `NotAllowedError` का आमतौर पर मतलब है कि उपयोगकर्ता ने समारोह पूरा नहीं किया। पासकी निर्माण के दौरान, वही त्रुटि अलग-अलग कारणों से सामने आती है: उपयोगकर्ता ने निर्माण संवाद को खारिज कर दिया (सशर्त निर्माण काम नहीं किया, या ऑटो-ट्रिगर अपेंड के दौरान पृष्ठ ने फोकस खो दिया)। ऑपरेशन प्रकार यह बदल देता है कि त्रुटि का क्या अर्थ है और आपको इसके बारे में क्या करना चाहिए। **समय अक्सर एक कम आंका गया संकेत है।** एक क्लिक के एक सेकंड से भी कम समय के बाद त्रुटि आमतौर पर एक तत्काल अस्वीकृति होती है (वातावरण ऐसा नहीं कर सकता, दस्तावेज़ केंद्रित नहीं है, क्षमता का अभाव है)। कुछ सेकंड के बाद एक त्रुटि एक उपयोगकर्ता कैंसल है (उन्होंने संवाद देखा और आगे न बढ़ने का फैसला किया)। 30+ सेकंड के बाद एक त्रुटि एक टाइमआउट है। नेटिव प्लेटफ़ॉर्म पर, समय विशेष रूप से महत्वपूर्ण है: ऑथेंटिकेटर राउंड-ट्रिप, बायोमेट्रिक प्रॉम्प्ट और क्रेडेंशियल मैनेजर हैंडऑफ़ सभी की विशिष्ट अवधि होती है जो आपको "उपयोगकर्ता दूर चला गया" से "काम नहीं किया" को अलग करने में मदद करती है। आप अभी भी आसानी से अंतर नहीं कर सकते हैं यदि एक पासकी मौजूद थी। ### 3.1 संदर्भ के साथ अस्पष्टता दूर करें आपको एक आदर्श संकेत की आवश्यकता नहीं है। आपको हर `NotAllowedError` को समान तरीके से मानने से बचने के लिए पर्याप्त संदर्भ की आवश्यकता है। iOS/Safari पर नीचे विशेष ध्यान दिया गया है क्योंकि इसमें अद्वितीय बाधाएं हैं (पहले के संस्करणों में उपयोगकर्ता सक्रियण आवश्यकताएं), लेकिन कच्चे त्रुटि मात्रा में, Windows और Chromium ब्राउज़र अक्सर किसी भी अन्य प्लेटफ़ॉर्म की तुलना में अधिक `NotAllowedError` उत्पन्न करते हैं। ये संकेत अक्सर आपको 80% रास्ते तक ले जाते हैं: | **संकेत** | **संभावित अर्थ** | **आगे क्या करें** | | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | तत्काल विफलता (`<1s`) | पर्यावरण अस्वीकृति: कोई क्षमता नहीं, दस्तावेज़ केंद्रित नहीं है, सशर्त निर्माण सतह अनुपलब्ध है | सुविधा का पता लगाने की जाँच करें; सुनिश्चित करें कि दस्तावेज़ पर फ़ोकस है; सत्यापित करें कि इस प्लेटफ़ॉर्म पर ऑपरेशन समर्थित है | | तेज़ कैंसल (1-3s) | आश्चर्यजनक प्रॉम्प्ट / कोई संदर्भ नहीं | प्रॉम्प्ट समय बदलें; कैंसल के बाद कूलडाउन जोड़ें | | उपयोगकर्ता-लंबाई कैंसल (3-15s) | उपयोगकर्ता ने संवाद देखा और आगे न बढ़ने का फैसला किया | अपेक्षित UX; UI पुनर्स्थापित करें + फ़ॉलबैक दिखाएं | | टाइमआउट (30s+) | समारोह उपयोगकर्ता कार्रवाई के बिना टाइम आउट हो गया | "पूरा नहीं हुआ" के रूप में बकेट करें; विचार करें कि क्या प्रॉम्प्ट पर ध्यान दिया गया था | | विफलता से पहले QR/हाइब्रिड UI दिखाई देता है | इस डिवाइस पर कोई स्थानीय क्रेडेंशियल उपलब्ध नहीं है। ध्यान दें: QR कोड निर्णयों के होने से पहले मज़बूती से पता लगाने के लिए एक [पासकी इंटेलिजेंस](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) लेयर की आवश्यकता होती है जो जानती हो कि क्या वर्तमान डिवाइस पर एक प्रयोग करने योग्य क्रेडेंशियल मौजूद है। | पासकी ऑफ़र गेट करें; "फ़ोन का उपयोग करें" को स्पष्ट करें; आश्चर्यजनक QR को कम करें | | iOS/Safari पर केंद्रित और बिना क्लिक/टैप के ट्रिगर किया गया | उपयोगकर्ता सक्रियण गायब है | एक वास्तविक उपयोगकर्ता जेस्चर से समारोह शुरू करें | | सशर्त निर्माण या ऑटो-ट्रिगर अपेंड के दौरान | ऑटोफ़िल उपलब्ध नहीं है, क्रेडेंशियल पहले से मौजूद है, या पृष्ठ का फोकस खो गया है। सुविधा लॉन्च होने पर सशर्त निर्माण त्रुटियां अचानक और उच्च मात्रा में दिखाई दे सकती हैं, जिससे यह रातोंरात सबसे बड़े त्रुटि स्रोतों में से एक बन जाता है। | सशर्त निर्माण देखें; दस्तावेज़ दृश्यता स्थिति जांचें; कॉल का प्रयास करने से पहले `conditionalCreate` समर्थन को सत्यापित करने के लिए `getClientCapabilities()` का उपयोग करें | यही कारण है कि `NotAllowedError` उपयोगकर्ता को शायद ही कभी दिखाई देनी चाहिए। यह ऐसा संदेश नहीं है जिस पर उपयोगकर्ता कार्रवाई कर सके। संदर्भ वर्गीकरण वह भी है जहां सफलता दर सबसे तेजी से विभाजित होती है। [Corbado Passkey Benchmark 2026 पासकी प्रमाणीकरण सफलता दर विश्लेषण](https://www.corbado.com/passkey-benchmark-2026/passkey-authentication-success-rate) बड़े पैमाने पर 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` में टाइमआउट को ढहते हुए देखती हैं। किसी भी तरह से, टाइमआउट को "समारोह पूरा नहीं हुआ" के रूप में मानें और समय और संदर्भ का उपयोग करके बकेट करें। ### 3.2 UX हैंडलिंग: कैंसल को एक सामान्य निकास बनाएं जब OS शीट को खारिज कर दिया जाता है या टाइम आउट हो जाता है, तो आपका UI तुरंत पुनर्प्राप्त होना चाहिए और शालीनता से प्रतिक्रिया करनी चाहिए। नियमों का एक व्यावहारिक सेट: - लॉगिन UI पुनर्स्थापित करें (कोई स्पिनर नहीं जो चलता रहे) - पहचानकर्ता स्थिति रखें (पुनः प्रविष्टि के लिए बाध्य न करें) - उसी स्क्रीन पर एक दृश्यमान फ़ॉलबैक दिखाएं - अपेक्षित परिणामों के लिए डरावने बैनरों से बचें मूल बातों से परे: - पहले निरस्त को सामान्य मानें और एक शांत स्पष्टीकरण के साथ पुनः प्रयास की पेशकश करें। केवल दूसरे गर्भपात के बाद ही आपको फ़ॉलबैक विकल्पों का सुझाव देना चाहिए (पासकी फ़ॉलबैक और पुनर्प्राप्ति देखें)। - कूलडाउन से पहले तीन तक निर्माण प्रॉम्प्ट की अनुमति दें ताकि हैरान उपयोगकर्ताओं को दूसरा मौका मिले (पासकी निर्माण सर्वोत्तम अभ्यास देखें)। - त्रुटि की गणना को निर्माण और लॉगिन के बीच विभाजित करें ताकि आप तुलना कर सकें। - OS, ब्राउज़र और डिवाइस द्वारा त्रुटि दर को विभाजित करें ताकि आप जान सकें कि वास्तव में घर्षण कहां रहता है (पासकी लॉगिन सर्वोत्तम अभ्यास देखें)। यदि आपके "कैंसल" वास्तव में अधिक हैं, तो अगला कदम उनके पीछे के मूल कारणों को ठीक करना है: प्रॉम्प्ट समय, QR आश्चर्य और कम उपलब्धता। ### 3.3 इंजीनियरिंग फिक्स जो NotAllowedError को कम करते हैं उन परिवर्तनों के साथ प्रारंभ करें जो मेट्रिक्स को जल्दी ले जाते हैं: - प्रॉम्प्ट समय और उपयोगकर्ता सक्रियता (विशेष रूप से 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() के साथ पासकी डिटेक्शन को ठीक करना देखें)। ### 3.4 विकसित होने वाले त्रुटि नामों पर ध्यान दें त्रुटि नाम एक गतिशील लक्ष्य हैं। अधिक दानेदार WebAuthn त्रुटियों को जोड़ने के लिए चल रहे प्रस्ताव हैं (उदाहरण के लिए, "कोई क्रेडेंशियल उपलब्ध नहीं है" को "उपयोगकर्ता ने रद्द कर दिया" से अलग करने के लिए)। फरवरी 2026 तक, यह किसी भी ब्राउज़र में लागू नहीं किया गया है, इसलिए संदर्भ और समय के आधार पर अपने स्वयं के कारण बकेट बनाना अभी भी उचित है। यदि आप इस काम को ट्रैक करना चाहते हैं, तो [WebAuthn issue #2062](https://github.com/w3c/webauthn/issues/2062) और ["New Error Codes" explainer](https://github.com/w3c/webauthn/wiki/Explainer%3A-New-Error-Codes-%282024-Edition%29) देखें। शेष त्रुटि नाम कम होते हैं लेकिन फिर भी वे जब सामने आते हैं तो समझने योग्य होते हैं। ## 4. AbortError: ऑपरेशन निरस्त कर दिया गया था `AbortError`, `NotAllowedError` की तुलना में मात्रा में असामान्य है, लेकिन जब यह प्रकट होता है तो यह अत्यधिक नैदानिक होता है: इसका आमतौर पर मतलब है कि समारोह समाप्त नहीं हुआ क्योंकि आपके ऐप ने अनुरोध को अमान्य कर दिया - नेविगेशन हुआ, स्थिति बदल गई, या दूसरा अनुरोध शुरू हो गया। **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | -------------- | --------------------------------------------------------- | | Chrome, Edge | `AbortError: The operation was aborted.` | | Chrome, Edge | `AbortError: Aborted by AbortSignal.` | | Firefox | `AbortError: signal is aborted without reason` | | Firefox | `AbortError: Operation timed out.` | | Safari, WebKit | `AbortError: The user aborted a request.` | | Chrome | `AbortError: CredentialContainer request is not allowed.` | सामान्य उत्पादन कारणों में शामिल हैं: - कई समवर्ती WebAuthn कॉल (दो प्रॉम्प्ट रेसिंग) - एक इन-फ़्लाइट समारोह के दौरान मार्ग परिवर्तन/री-रेंडर - रिट्री या स्टेट क्लीनअप के दौरान `AbortController.abort()` को कॉल करना इसे ठीक करने के लिए, समारोह को एक "महत्वपूर्ण खंड" बनाने पर ध्यान दें: - एक समय में केवल एक इन-फ़्लाइट अनुरोध की अनुमति दें - समारोह के दौरान नेविगेशन को रोकें (या स्पष्ट रूप से रद्द करें और UI पुनर्स्थापित करें) - गर्भपात को अपेक्षित नियंत्रण प्रवाह के रूप में मानें: एक पुनः प्रयास बटन और एक फ़ॉलबैक विधि दिखाएं यदि आप एम्बेडेड सतहों या मल्टी-डोमेन ऐप्स में केंद्रित `AbortError` देखते हैं, तो जांच करने के लिए अगली बकेट `SecurityError` है। ## 5. SecurityError: TLS प्रमाणपत्र त्रुटियों वाली साइटों पर WebAuthn समर्थित नहीं है `SecurityError` वह ब्राउज़र है जो आपको बता रहा है: "इस संदर्भ को आपने जो पूछा है उसे करने की अनुमति नहीं है।" व्यवहार में यह लगभग हमेशा कॉन्फ़िगरेशन होता है, उपयोगकर्ता का व्यवहार नहीं। परिपक्व उत्पादन तैनाती में, `SecurityError` दुर्लभ है क्योंकि ये समस्याएं आमतौर पर एकीकरण परीक्षण के दौरान पकड़ी जाती हैं। यदि यह उत्पादन में प्रकट होता है, तो इसका आमतौर पर मतलब है कि एक नया डोमेन, एम्बेडिंग संदर्भ, या परिनियोजन लक्ष्य उचित WebAuthn कॉन्फ़िगरेशन के बिना जोड़ा गया था। सामान्य कारणों में शामिल हैं: - RP ID / ओरिजिन बेमेल (मल्टी-डोमेन सेटअप) - क्रॉस-ओरिजिन एम्बेडिंग प्रतिबंध (iframe) - असुरक्षित संदर्भ (HTTPS नहीं) या अवरुद्ध अनुमतियां/नीतियां - `.well-known/webauthn` या `.well-known/assetlinks.json` गलत कॉन्फ़िगर किया गया है, गायब है, या अस्थायी रूप से अनुपलब्ध है। उस महत्वपूर्ण विंडो के दौरान नेटवर्क समस्याएं जब ब्राउज़र इन फ़ाइलों को प्राप्त करता है, विफलताओं का कारण बनेंगी। एक सामान्य अंधा स्थान: यदि आपका होमपेज रखरखाव के लिए डाउन है, तो well-known फाइलें भी ऑफ़लाइन हैं, जो उन पर निर्भर करने वाले सभी आश्रित पक्षों में पासकी समारोहों को तोड़ देती हैं। **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Chrome, Edge | `SecurityError: WebAuthn is not supported on sites with TLS certificate errors.` | | कोई भी ब्राउज़र | `SecurityError: The relying party ID is not a registrable domain suffix of, nor equal to the current origin's effective domain.` | | Chrome (iframe) | `SecurityError: The 'publickey-credentials-create' feature is not enabled in this document.` | उत्पादन में, `SecurityError` दुर्लभ हैं - इन्हें लगभग हमेशा एकीकरण परीक्षण के दौरान पकड़ा जाता है। जब वे दिखाई देते हैं, तो TLS प्रमाणपत्र त्रुटि सबसे आम उत्तरजीवी है। सबसे तेज़ डीबगिंग लूप है: - आपके द्वारा उपयोग किए गए ओरिजिन और RP ID इनपुट को लॉग करें - उसी संदर्भ में पुनरुत्पादन करें (शीर्ष-स्तर बनाम iframe, prod डोमेन बनाम स्टेजिंग) - यदि आप लॉगिन एम्बेड करते हैं, तो पुष्टि करें कि अनुमतियां नीति कॉन्फ़िगर की गई है (उदाहरण के लिए `publickey-credentials-create` / `publickey-credentials-get`): [MDN Permissions-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy/publickey-credentials-create) - अपनी डोमेन रणनीति को सत्यापित करें (संबंधित ओरिजिन देखें) - यदि आप iframes का उपयोग करते हैं, तो सुविधा नीतियों को मान्य करें (iframe पासकी देखें) एक बार `SecurityError` को संभाल लिया जाता है, गंभीरता से इलाज करने वाली अगली बकेट त्रुटियों का सेट है जो अक्सर कार्यान्वयन बग का संकेत देती है: `InvalidStateError`, `ConstraintError` और `DataError`। ## 6. InvalidStateError, ConstraintError, DataError: कार्यान्वयन बग के रूप में व्यवहार करें एक परिपक्व पासकी कार्यान्वयन में ये त्रुटियां दुर्लभ होनी चाहिए। जब वे दिखाई देते हैं, तो वे आम तौर पर संकेत देते हैं कि किसी खंड के लिए विकल्प निर्माण गलत है या प्रवाह गलत स्थिति में है। ### 6.1 InvalidStateError: "क्रेडेंशियल पहले से ही रिलाइंग पार्टी के साथ पंजीकृत हैं" **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Safari, WebKit | `InvalidStateError: The user attempted to register an authenticator that contains one of the credentials already registered with the relying party.` | | Chrome, Edge | `InvalidStateError: At least one credential matches an entry of the excludeCredentials list in the platform attached authenticator.` | | Chrome, Edge | `InvalidStateError: A request is already pending.` | | Firefox | `InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable` | विशिष्ट अर्थ: - पंजीकरण: आपने एक क्रेडेंशियल बनाने का प्रयास किया जो पहले से मौजूद है (डुप्लिकेट) - लॉगिन: कम आम; अक्सर इसका मतलब है कि प्रवाह/स्थिति प्लेटफ़ॉर्म के लिए असंगत है व्यावहारिक संचालन: - यदि यह मैन्युअल पंजीकरण में होता है, तो इसे "पहले से ही नामांकित" के रूप में मानें और उसी के अनुसार मार्ग करें - सुनिश्चित करें कि `excludeCredentials` उपयोगकर्ता के लिए सभी मौजूदा क्रेडेंशियल आईडी को सूचीबद्ध करता है ताकि ऑथेंटिकेटर डुप्लिकेट का पता लगा सके (`excludeCredentials` देखें) - सशर्त निर्माण के दौरान, `InvalidStateError` अपेक्षित है और इसे चुपचाप अनदेखा किया जाना चाहिए: इसका मतलब है कि प्रदाता में एक पासकी पहले से मौजूद है। यही बात सशर्त निर्माण के दौरान `NotAllowedError` और `AbortError` पर भी लागू होती है ([Chrome पर सशर्त निर्माण](https://developer.chrome.com/docs/identity/webauthn-conditional-create) देखें) ### 6.2 ConstraintError विशिष्ट अर्थ: ऑथेंटिकेटर आपके अनुरोधित बाधाओं को संतुष्ट नहीं कर सकता है। सामान्य ट्रिगर: - डिवाइस स्क्रीन लॉक गायब है (विशेष रूप से Android): प्लेटफ़ॉर्म को बायोमेट्रिक या पिन सत्यापन की आवश्यकता होती है लेकिन डिवाइस में कोई लॉक स्क्रीन कॉन्फ़िगर नहीं है - बहुत सख्त `authenticatorAttachment` या निवासी कुंजी धारणाएँ - उन खंडों में कठिन `userVerification` आवश्यकताएँ जहाँ वे उपलब्ध नहीं हैं सुधार: बाधाओं को आराम दें (जहां स्वीकार्य हो) या एक वैकल्पिक मार्ग प्रदान करें। स्क्रीन लॉक न होने के लिए, चुपचाप विफल होने (Android) के बजाय इस स्थिति का पता लगाने और उपयोगकर्ताओं का मार्गदर्शन करने पर विचार करें। ### 6.3 DataError विशिष्ट अर्थ: इनपुट विकृत या असंगत हैं। सामान्य ट्रिगर: - एन्कोडिंग गलतियाँ (base64 बनाम base64url) - अमान्य क्रेडेंशियल आईडी / चुनौती स्वरूपण सुधार: उस सीमा पर इनपुट को मान्य और सामान्य करें जहां आप WebAuthn विकल्प उत्पन्न करते हैं। व्यवहार में, `DataError` परिपक्व उत्पादन प्रणालियों में प्रभावी रूप से अनुपस्थित है - यदि आपका विकल्प जनरेशन परीक्षण किया गया है, तो आप इसे डैशबोर्ड में नहीं देखेंगे। यदि ये त्रुटियां नियंत्रण में हैं, तो अगला प्रश्न कवरेज का है: क्या उपयोगकर्ता विफल हो रहे हैं क्योंकि वातावरण आपकी अपेक्षा के अनुसार WebAuthn नहीं कर सकता है? ## 7. NotSupportedError: उपयोगकर्ता एजेंट सार्वजनिक कुंजी क्रेडेंशियल्स का समर्थन नहीं करता है `NotSupportedError` एक कवरेज सिग्नल है, विश्वसनीयता सिग्नल नहीं। इसका आमतौर पर मतलब है कि कोई खंड वह नहीं कर सकता जो आपने पूछा था (OS/ब्राउज़र बहुत पुराना, लापता क्षमता, सुविधा सक्षम नहीं)। **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | --------------------- | ---------------------------------------------------------------------------------------------- | | Chrome, Edge | `NotSupportedError: The user agent does not support public key credentials.` | | Firefox | `NotSupportedError: Resident credentials or empty 'allowCredentials' lists are not supported.` | | Chrome, Edge, Firefox | `TypeError: PublicKeyCredential.parseCreationOptionsFromJSON is not a function` | | Chrome, Edge, Firefox | `TypeError: PublicKeyCredential.parseRequestOptionsFromJSON is not a function` | | Chrome, Edge, Firefox | `TypeError: credential.toJSON is not a function` | | Safari | `TypeError: Can only call PublicKeyCredential.toJSON on instances of PublicKeyCredential` | पहले दो वास्तविक `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` के रूप में सामने आने वाले प्लेटफ़ॉर्म-लेयर मुद्दों से निपट सकते हैं। ## 8. UnknownError: क्रेडेंशियल मैनेजर से बात करते समय एक अज्ञात त्रुटि हुई `UnknownError` ऑथेंटिकेटर/OS विफलताओं के लिए एक कैच-ऑल है जो अन्य श्रेणियों में सफाई से मैप नहीं करते हैं। यह अक्सर क्षणिक होता है, लेकिन OS अपडेट के बाद भी यह बढ़ सकता है। **आप ब्राउज़र कंसोल में क्या देखेंगे:** | **स्रोत** | **त्रुटि संदेश** | | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- | | Chrome (Android) | `UnknownError: An unknown error occurred while talking to the credential manager.` | | कोई भी ब्राउज़र | `UnknownError: The operation failed for an unknown transient reason.` | | कोई भी ब्राउज़र | `UnknownError: Either the device has received unexpected request data, or the device has been reconfigured since the request was made.` | | कोई भी ब्राउज़र | `UnknownError: Something went wrong.` | | Chrome (LastPass) | `TypeError: Cannot use 'in' operator to search for 'type' in null` | | Safari (LastPass) | `TypeError: null is not an Object. (evaluating 'key in input')` | | Chrome (Bitwarden) | `FallbackRequested` | व्यावहारिक हैंडलिंग: - रिट्री-फ्रेंडली UX का उपयोग करें (उपयोगकर्ता को "दोष" न दें) - जहां संभव हो OS/बिल्ड नंबर और क्रेडेंशियल-मैनेजर/प्रदाता संदर्भ कैप्चर करें - OS अपडेट के बाद सेगमेंट-विशिष्ट स्पाइक्स पर नज़र रखें त्रुटियों का एक विशिष्ट स्रोत जो किसी भी `DOMException` श्रेणी में अच्छी तरह से फिट नहीं होता है: **पासवर्ड मैनेजर ब्राउज़र एक्सटेंशन** (जैसे Bitwarden, LastPass, 1Password, और अन्य) WebAuthn API कॉल को रोक सकते हैं और गैर-मानक प्रतिक्रियाएं दे सकते हैं। जबकि उपयोगकर्ता रद्दीकरण की तुलना में मात्रा में छोटा है, वे ट्रैक करने लायक हैं क्योंकि वे लगातार विशिष्ट उपयोगकर्ता खंडों को प्रभावित करते हैं और लक्षण भ्रामक होते हैं: लौटे क्रेडेंशियल ऑब्जेक्ट पर लापता विधियां, अप्रत्याशित त्रुटि प्रकार, या विकृत प्रतिक्रियाएं जो किसी भी प्रलेखित WebAuthn त्रुटि से मेल नहीं खाती हैं। ये अक्सर `UnknownError` या अवर्गीकृत अपवादों के रूप में सामने आते हैं। यदि आप बिना किसी OS-स्तरीय स्पष्टीकरण के विशिष्ट ब्राउज़रों में केंद्रित त्रुटि स्पाइक्स देखते हैं, तो जांचें कि क्या क्रेडेंशियल मैनेजर एक्सटेंशन शामिल है। अब तक हमने वेब ब्राउज़र त्रुटि नामों को कवर किया है। लेकिन यदि आप नेटिव ऐप भी शिप करते हैं, तो त्रुटि परिदृश्य अलग है - और कुछ मायनों में, काफी बेहतर है। ## 9. नेटिव ऐप्स (iOS और Android) पर एक शब्द उपरोक्त सब कुछ वेब ब्राउज़रों को कवर करता है। नेटिव ऐप्स - 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 कारण श्रृंखलाओं के साथ संरचित त्रुटि प्रकार देता है। इससे डिबगिंग आसान हो जाती है लेकिन इसका मतलब है कि आपके त्रुटि प्रबंधन को स्थानीयकरण और प्लेटफ़ॉर्म-विशिष्ट त्रुटि प्रारूपों का हिसाब रखना होगा। ### 9.1 iOS (ASAuthorization फ्रेमवर्क) iOS ASAuthorization फ्रेमवर्क के माध्यम से पासकी त्रुटियों को सामने लाता है। सभी त्रुटियां `authorizationController(controller:didCompleteWithError:)` डेलिगेट कॉलबैक में `NSError` ऑब्जेक्ट के रूप में आती हैं। **डोमेन + कोड द्वारा वर्गीकृत करें, संदेश स्ट्रिंग द्वारा नहीं।** प्राथमिक त्रुटि डोमेन `com.apple.AuthenticationServices.AuthorizationError` (`ASAuthorizationError.errorDomain`) है। `let nsError = error as NSError` के साथ त्रुटि को कास्ट करें और `.domain` और `.code` पर मिलान करें। उत्पादन में कभी भी `.localizedDescription` पर मिलान न करें - Apple के संदेशों को 30+ भाषाओं में स्थानीयकृत किया जाता है और OS संस्करणों में बदला जा सकता है। नीचे सूचीबद्ध संदेश स्ट्रिंग लॉग में त्रुटियों को पहचानने के लिए उपयोगी हैं, लेकिन वे वर्गीकरण मानदंड नहीं हैं। **सार्वजनिक ASAuthorizationError कोड:** | **कोड** | **नाम** | **कब से** | **इसका क्या मतलब है** | | ------- | --------------------------------------- | --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1000 | `Unknown` | iOS 13 | उत्पादन में नहीं दिखाई देना चाहिए। सामान्य कैच-ऑल। | | 1001 | `Canceled` | iOS 13 | उपयोगकर्ता ने पासकी शीट को खारिज कर दिया। कुल मिलाकर सबसे आम त्रुटि - `NotAllowedError` समतुल्य। खाली `userInfo` और बिना किसी अंतर्निहित त्रुटि के साफ संकेत। | | 1002 | `InvalidResponse` | iOS 13 | फ्रेमवर्क-स्तरीय भ्रष्टाचार। व्यवहार में दुर्लभ। | | 1003 | `NotHandled` | iOS 13 | किसी भी प्रदाता ने अनुरोध को नहीं संभाला। एंटाइटेलमेंट और क्रेडेंशियल प्रदाता कॉन्फ़िगरेशन की जांच करें। | | 1004 | `Failed` | iOS 13 | सामान्य विफलता। `localizedDescription` में वास्तविक कारण होता है (उदा. "Application with identifier X is not associated with domain Y")। `userInfo` में `FailureReason` स्ट्रिंग हो सकती है, लेकिन `NSUnderlyingErrorKey` हमेशा पॉप्युलेट नहीं होती है - डोमेन एसोसिएशन विफलताएं अंतर्निहित त्रुटि के लिए शून्य (nil) लौटाती हैं। | | 1005 | `NotInteractive` | iOS 15 | `preferImmediatelyAvailableCredentials` का उपयोग करते समय कोई क्रेडेंशियल उपलब्ध नहीं है। यह साफ़ "नहीं मिला" संकेत है - "इस डिवाइस पर कोई पासकी मौजूद नहीं है" का iOS समतुल्य। कोई UI नहीं दिखाया गया। | | 1006 | `MatchedExcludedCredential` | iOS 18 | इस डिवाइस पर इस RP के लिए एक पासकी पहले से मौजूद है। डुप्लिकेट डिटेक्शन के लिए क्लीन सिग्नल - खाली `userInfo`, कोई `NSUnderlyingErrorKey` नहीं। वर्गीकरण स्ट्रिंग मिलान के बिना काम करता है। | | 1007 | `CredentialImport` | iOS 18.2 | क्रेडेंशियल आयात विफल रहा। | | 1008 | `CredentialExport` | iOS 18.2 | क्रेडेंशियल निर्यात विफल रहा। | | 1009 | `PreferSignInWithApple` | iOS 26 | उपयोगकर्ता पासकी के बजाय Sign in with Apple पसंद करता है। iOS 26 में नया। | | 1010 | `DeviceNotConfiguredForPasskeyCreation` | iOS 26 | डिवाइस में पासकोड या iCloud कीचेन कॉन्फ़िगरेशन का अभाव है। ज्ञात iOS 26 सिम्युलेटर बग: कॉन्फ़िगरेशन सही होने पर भी 1010 लौटाता है (भौतिक उपकरणों पर पुनरुत्पादन नहीं करता है)। | उत्पादन के लिए सबसे महत्वपूर्ण अंतर: **iOS 18 के बाद से, डुप्लिकेट क्रेडेंशियल्स अपना स्वयं का त्रुटि कोड 1006 (`MatchedExcludedCredential`) लौटाते हैं।** iOS 17 और इससे पहले पर, डुप्लिकेट क्रेडेंशियल्स कोड 1004 (`Failed`) के अंदर छिपे हुए थे। iOS 18+ पर, अंतर संरचनात्मक (अलग त्रुटि कोड) है, टेक्स्टुअल नहीं। **सामान्य रनटाइम त्रुटियां (लॉग-स्तरीय संदर्भ):** ये संदेश विशिष्ट विफलता परिदृश्यों के लिए `localizedDescription` या `userInfo` में दिखाई देते हैं। उनका उपयोग लॉग खोज और डिबगिंग के लिए करें, न कि प्रोग्रामेटिक वर्गीकरण के लिए। | **संदेश (अंग्रेजी लोकेल)** | **अंतर्निहित कोड** | **टिप्पणियाँ** | | ------------------------------------------------------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Application with identifier is not associated with domain X` | 1004 (`Failed`) | ऐप का Associated Domains एंटाइटेलमेंट रिलाइंग पार्टी से मेल नहीं खाता है। अपने सर्वर पर `apple-app-site-association` फ़ाइल को ठीक करें। | | `Couldn't communicate with a helper application.` | 1004 (`Failed`) | क्रेडेंशियल प्रदाता एक्सटेंशन प्रतिक्रिया देने में विफल रहा। क्षणिक - पुनः प्रयास उचित है। | | `Request already in progress for specified application identifier.` | 1004 (`Failed`) | एक डुप्लिकेट ASAuthorization अनुरोध फायर किया गया था जबकि एक लंबित था। ऐप में रेस कंडीशन। | | `Stolen Device Protection is enabled and biometry is required.` | 1004 (`Failed`) | iOS 17+ Stolen Device Protection अपरिचित स्थानों में बायोमेट्रिक प्रमाणीकरण को रोकता है। डेवलपर्स द्वारा कार्रवाई योग्य नहीं है, लेकिन उपयोगकर्ता के सामने लाने लायक है। | | `(AuthenticationServicesCore.ASCABLEClient.ClientError error 2.)` | Separate domain | क्रॉस-डिवाइस प्रमाणीकरण (हाइब्रिड/CABLE) ब्लूटूथ हैंडशेक विफल रहा। | | `(AuthenticationServicesCore.ASCABLEClient.ClientError error 3.)` | Separate domain | क्रॉस-डिवाइस प्रमाणीकरण ब्लूटूथ कनेक्शन विफल रहा। | **स्थानीयकृत "कोई क्रेडेंशियल नहीं" संदेश (कोड 1005):** जब `preferImmediatelyAvailableCredentials` सेट किया जाता है और कोई पासकी मौजूद नहीं होती है, तो iOS उपयोगकर्ता की डिवाइस भाषा में स्थानीयकृत संदेश के साथ कोड 1005 (`NotInteractive`) लौटाता है। यह नेटिव ऐप्स के लिए अद्वितीय है - वेब ब्राउज़र इस संकेत को कभी उजागर नहीं करते हैं। संदेश हमेशा `The operation couldn't be completed.` के साथ शुरू होता है, जिसके बाद स्थानीयकृत टेक्स्ट होता है: | **भाषा** | **संदेश** | | --------------------- | ------------------------------------------------------------------------------------ | | Chinese (Simplified) | `没有可用于登录的凭证。` | | Vietnamese | `Không có sẵn thông tin để đăng nhập.` | | Arabic | `لا تتوفر بيانات اعتماد لتسجيل الدخول.` | | Spanish | `No hay ninguna credencial disponible para iniciar sesión.` | | Chinese (Traditional) | `沒有可用於登入的憑證。` | | Korean | `로그인을 위한 자격 증명이 없습니다.` | | French (Canada) | `Aucun identifiant disponible pour la connexion.` | | Portuguese (Brazil) | `Nenhuma credencial disponível para login.` | | French (France) | `Aucune information d'identification n'est disponible pour procéder à la connexion.` | | Thai | `ไม่มีข้อมูลประจำตัวสำหรับเข้าสู่ระบบ` | | Italian | `Non ci sono credenziali disponibili per l'accesso.` | | Dutch | `Geen inloggegevens beschikbaar.` | | Japanese | `ログイン用の資格情報がありません。` | | Turkish | `Oturum açmak için kullanılabilecek kimlik bilgisi yok.` | अंग्रेजी-लोकेल डिवाइस आमतौर पर API स्तर पर "कोई क्रेडेंशियल नहीं" का समाधान करते हैं, इससे पहले कि ASAuthorization ढांचा स्थानीयकृत त्रुटि लौटाए, यही वजह है कि ऊपर कोई अंग्रेजी संस्करण दिखाई नहीं देता है। प्रोग्रामेटिक रूप से, इन स्ट्रिंग्स को पार्स करने के बजाय हमेशा कोड 1005 पर मिलान करें। ### 9.2 Android (Credential Manager API) Android Credential Manager API (`androidx.credentials`) के माध्यम से पासकी त्रुटियों को सामने लाता है। त्रुटि संदेशों में एक प्राथमिक संदेश और अक्सर अतिरिक्त विवरण के साथ एक `cause` शामिल होता है। iOS की तुलना में, Android कॉन्फ़िगरेशन मुद्दों के लिए अधिक संरचित त्रुटि प्रकार और अधिक स्पष्ट कारण प्रदान करता है। **उपयोगकर्ता रद्दीकरण और क्रेडेंशियल पहचान:** | **त्रुटि** | **टिप्पणियाँ** | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `User cancelled the operation` | उपयोगकर्ता ने पासकी प्रॉम्प्ट को खारिज कर दिया। `NotAllowedError` समतुल्य। ध्यान दें: क्रेडेंशियल मैनेजर एक अलग कोड पथ से `User canceled the request` (US स्पेलिंग) भी लौटाता है - दोनों समान हैं। | | `Excluded credential matches existing credential` | इस क्रेडेंशियल आईडी के लिए एक पासकी पहले से मौजूद है। `InvalidStateError` समतुल्य। iOS के विपरीत, संदेश उपयोगकर्ता रद्दीकरण से अलग है। | | `No create options available.` | कोई भी योग्य क्रेडेंशियल प्रदाता निर्माण अनुरोध को नहीं संभाल सकता है। आमतौर पर इसका मतलब है कि Google Play Services पुरानी है या कोई भी क्रेडेंशियल प्रदाता पासकी निर्माण का समर्थन नहीं करता है। | **कॉन्फ़िगरेशन और सुरक्षा त्रुटियां:** | **त्रुटि** | **टिप्पणियाँ** | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | `Passkeys not supported for this app` | डिजिटल एसेट लिंक (`assetlinks.json`) गायब है या इसमें ऐप का साइनिंग सर्टिफिकेट फिंगरप्रिंट नहीं है। `SecurityError` समतुल्य। | | `Https failed: respCode=301, url=https:///.well-known/assetlinks.json` | `assetlinks.json` फ़ाइल HTTP 200 के बजाय रीडायरेक्ट लौटाती है। Android को रीडायरेक्ट के बिना सटीक URL पर फ़ाइल की आवश्यकता होती है। | | `The incoming request cannot be validated` | क्रेडेंशियल मैनेजर डिजिटल एसेट लिंक के विरुद्ध अनुरोध को सत्यापित नहीं कर सकता है। | | `RP ID cannot be validated.` | WebAuthn विकल्पों में रिलाइंग पार्टी आईडी `assetlinks.json` से मेल नहीं खाती है। | | `Screen lock is missing.` | डिवाइस पर कोई पिन, पैटर्न या बायोमेट्रिक कॉन्फ़िगर नहीं किया गया है। पासकी को उपयोगकर्ता सत्यापन की आवश्यकता होती है। `ConstraintError` समतुल्य। | | `Cannot find an eligible account.` | डिवाइस पर कोई भी Google खाता पासकी निर्माण के लिए योग्य नहीं है (दुर्लभ, आमतौर पर कस्टम एंटरप्राइज़ सेटअप)। | **प्लेटफ़ॉर्म और ऑथेंटिकेटर त्रुटियां:** | **त्रुटि** | **टिप्पणियाँ** | | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Unsuccessful result from folsom activity.` | Google Play Services आंतरिक विफलता। "Folsom" पासकी संचालन के लिए एक GMS घटक है। क्षणिक - पुनः प्रयास उचित है। | | `Can't find the proper key to decrypt the private key from WebauthnCredentialSpecifics.` | एक समन्वयित (synced) पासकी मौजूद है लेकिन डिवाइस इसकी निजी कुंजी को डिक्रिप्ट नहीं कर सकता है। Google Password Manager सिंक स्थिति असंगत है - क्रेडेंशियल को किसी अन्य डिवाइस से समन्वयित किया गया था लेकिन डिक्रिप्शन कुंजी अनुपलब्ध है। डेवलपर्स द्वारा कार्रवाई योग्य नहीं है। | | `Operation was interrupted` (cause: `The UI was interrupted - please try again.`) | क्रेडेंशियल मैनेजर UI किसी अन्य गतिविधि (आने वाली कॉल, स्क्रीन रोटेशन, ऐप बैकग्राउंडेड) द्वारा बाधित किया गया था। `AbortError` समतुल्य। | | `Unknown credential error` | सामान्य कैच-ऑल जब कोई विशिष्ट त्रुटि प्रकार लागू नहीं होता है। आमतौर पर क्षणिक। | | `timeout` (cause: `Canceled`) | उपयोगकर्ता द्वारा बायोमेट्रिक सत्यापन पूरा करने से पहले क्रेडेंशियल मैनेजर ऑपरेशन टाइम आउट हो गया। | ## 10. इसे एक साथ रखना: त्रुटि वर्गीकरण निम्नलिखित आरेख दिखाता है कि ऊपर चर्चा की गई सभी परतें - इन्फ्रास्ट्रक्चर, पर्यावरण, ऑपरेशन प्रकार, वर्गीकरण और डिटेक्शन - एक छोर से दूसरे छोर तक कैसे जुड़ते हैं। यह वह मानसिक मॉडल है जिसे आपको अपनी त्रुटि ट्रैकिंग डिज़ाइन करते समय ध्यान में रखना चाहिए। ```mermaid 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["सर्वर साइड त्रुटि
500 / लॉजिक त्रुटि"]:::network NetErr["नेटवर्क त्रुटि
टाइमआउट / 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 संस्करण / सेटिंग्स
(स्क्रीन लॉक, बायोमेट्रिक्स)"] 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
+ संस्करण"] App["नेटिव ऐप / वेबव्यू
+ ऐप संस्करण"] OS_Ver --> Browser OS_Ver --> App end %% Layer 4: WebAuthn Operation subgraph Op_Layer ["परत 4: WebAuthn ऑपरेशन"] OpType{"ऑपरेशन प्रकार"} Login["लॉगिन
(navigator.credentials.get)"] Reg["पंजीकरण
(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["अपेक्षित त्रुटि
(उपयोगकर्ता ने समारोह रद्द कर दिया)"]:::expected Unexp["अप्रत्याशित त्रुटि
(सिस्टम/क्रैश/अज्ञात)"]:::unexpected ClientManifest --> Classification Sub_CUI & Sub_Auto & Sub_CDA --> Classification Classification --> Exp Classification --> Unexp %% Detection Logic subgraph Detection ["डिटेक्शन लक्ष्य"] P1["P1: लॉगिन समस्याएँ"] P2["P2: निर्माण समस्याएँ"] Baseline["बेसलाइन ड्रिफ्ट का पता लगाएं
(बढ़ा हुआ अपेक्षित)"] NewErr["नई विसंगतियों का पता लगाएं
(बढ़ा हुआ अप्रत्याशित)"] end Exp --> Baseline Unexp --> NewErr Exp & Unexp --> P1 & P2 %% Actionable Outcomes subgraph Action ["शमन कार्रवाई"] Fix["हॉटफिक्स तैनात करें / नया संस्करण"]:::action Fallback["स्वचालित फ़ॉलबैक सक्रिय करें
(पासकी अक्षम करें)"]:::action end P1 & P2 & NewErr --> Fix P1 & P2 & NewErr --> Fallback end %% Connectors Infrastructure -.-> Environment ``` मुख्य अंतर्दृष्टि: एक कच्चा `error.name` केवल तभी समझ में आता है जब आप जानते हैं कि पर्यावरण की किस परत ने इसे उत्पन्न किया, कौन सा ऑपरेशन चल रहा था और क्या त्रुटि अपेक्षित थी या अप्रत्याशित थी। नीचे दिए गए अनुभाग शामिल करते हैं कि क्या लॉग करना है और उस पर कैसे कार्य करना है। ## 11. क्या लॉग करें ताकि त्रुटियां डीबग करने योग्य बन जाएं इस लेख में अधिकांश त्रुटि वर्गीकरण अकेले क्लाइंट-साइड संकेतों के साथ किया जा सकता है। एक फ्रंटएंड-ओनली ऑब्ज़र्वेबिलिटी SDK अधिकांश WebAuthn त्रुटियों को वर्गीकृत करने के लिए पर्याप्त संदर्भ कैप्चर करता है। इसी तरह Corbado का ऑब्ज़र्वेबिलिटी SDK भी आर्किटेक्ट किया गया है: क्लाइंट-साइड लेयर त्रुटि एट्रिब्यूशन, समय, ऑपरेशन संदर्भ और प्लेटफ़ॉर्म डिटेक्शन को संभालती है। सर्वर-साइड लॉगिंग उन विफलताओं के लिए एक दूसरी परत जोड़ता है जिन्हें केवल बैकएंड ही देख सकता है। मुख्य आवश्यकता: हर प्रयास को एंड-टू-एंड जुड़ने योग्य होना चाहिए। एक साझा सहसंबंध आईडी (उदा. `auth_flow_id`) क्लाइंट-साइड संदर्भ को सर्वर सत्यापन परिणाम से जोड़ता है। ### 11.1 क्लाइंट-साइड सिग्नल (फ्रंटएंड SDK) | **सिग्नल** | **यह क्यों मायने रखता है** | | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `error.name` + सामान्यीकृत कारण बकेट | कच्ची ब्राउज़र त्रुटि + आपका वर्गीकरण | | ऑपरेशन प्रकार | सशर्त UI, मोडल लॉगिन, मैन्युअल निर्माण, सशर्त निर्माण, ऑटो-अपेंड। **CDA (क्रॉस-डिवाइस ऑथ)** अपने आप में एक जटिल जानवर है। | | पूर्ण पर्यावरण संदर्भ | OS + संस्करण, ब्राउज़र + संस्करण, **हार्डवेयर ब्रांड/मॉडल**, **ऑथेंटिकेटर सेटिंग्स** (उदा., GPM सक्षम है?) | | ऑथेंटिकेटर / क्रेडेंशियल मैनेजर संदर्भ | एक्सटेंशन और प्रदाता टूटना | | ऑपरेशन शुरू होने से त्रुटि तक का समय | तत्काल अस्वीकृति (`<1s`) बनाम उपयोगकर्ता कैंसल (1-15s) बनाम टाइमआउट (30s+) | | नेटवर्क / कनेक्टिविटी स्थिति | नेटवर्क त्रुटियां अक्सर क्लाइंट त्रुटियों के रूप में प्रकट होती हैं। ट्रैक करें कि क्या उपयोगकर्ता ऑफ़लाइन था और कनेक्टिविटी बहाल होने पर भेजने के लिए **लॉग कतारबद्ध करें**। | | क्या QR/हाइब्रिड UI दिखाई दिया | स्थानीय बनाम क्रॉस-डिवाइस विफलता | | सहसंबंध आईडी (`auth_flow_id`) | सर्वर लॉग के साथ जुड़ें | ### 11.2 सर्वर-साइड सिग्नल (बैकएंड सत्यापन) ब्राउज़र द्वारा एक क्रेडेंशियल और हस्ताक्षरित चुनौती लौटाए जाने के बाद सर्वर सत्यापन विफलताएं होती हैं। ये स्पष्ट कोड के साथ संरचित त्रुटियां होनी चाहिए, न कि क्लाइंट-साइड `DOMException` नामों के समान बकेट में मिश्रित। WebAuthn सर्वर कार्यान्वयन देखें। | **सिग्नल** | **यह क्यों मायने रखता है** | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | चुनौती बेमेल / समाप्त चुनौती | सत्र समय या रीप्ले समस्याएं | | ओरिजिन / RP ID बेमेल | मल्टी-डोमेन कॉन्फ़िगरेशन बग | | अमान्य हस्ताक्षर / क्रेडेंशियल नहीं मिला | हटाया गया या दूषित क्रेडेंशियल। सामान्य मामला: एक पासकी के साथ सशर्त UI लॉगिन जिसे उपयोगकर्ता पहले ही सर्वर-साइड हटा चुका है। क्लाइंट और सर्वर क्रेडेंशियल सूचियों को सिंक में रखने के लिए सिग्नल API का उपयोग करें। | | उपयोगकर्ता हैंडल बेमेल | खाता मानचित्रण समस्याएँ | | सहसंबंध आईडी (`auth_flow_id`) | क्लाइंट-साइड संदर्भ के साथ जुड़ें | यदि आप एक पूर्ण फ़नल मॉडल (चरण और चरणों के बीच रूपांतरण द्वारा ड्रॉप-ऑफ़) चाहते हैं, तो ड्रॉप-ऑफ़ को समझने के लिए पासकी टेलीमेट्री देखें। [Watch on YouTube](https://www.youtube.com/watch?v=wnrXJzvBjsU) इस डेटा के साथ, निष्कर्ष सरल हो जाता है: अधिकांश "त्रुटियां" या तो UX फिक्स, कवरेज फिक्स, या कॉन्फ़िगरेशन फिक्स बन जाती हैं। लेकिन इस वर्गीकरण को स्वयं बनाना और बनाए रखना महत्वपूर्ण चल रहा काम है। ## 12. त्रुटि नामों से परे: Corbado कैसे कच्चे त्रुटियों को कार्रवाई योग्य संकेतों में बदलता है ऊपर दी गई लॉगिंग चेकलिस्ट कच्चे संकेतों को कैप्चर करती है। बड़े पैमाने पर उत्पादन में, अकेले `error.name` पर्याप्त नहीं है। इस वर्गीकरण को स्वयं बनाना महत्वपूर्ण चल रहा काम है: त्रुटि संदेश हर ब्राउज़र और OS रिलीज़ के साथ बदलते हैं, पासवर्ड मैनेजर प्रदाता ऐसे अपडेट शिप करते हैं जो समारोह के व्यवहार को बदलते हैं और हर फीचर लॉन्च के साथ नए त्रुटि हस्ताक्षर दिखाई देते हैं। ### 12.1 केवल `error.name` ही पर्याप्त क्यों नहीं है एक ही `NotAllowedError` का मतलब छह अलग-अलग चीजें हो सकती हैं जो तीन आयामों पर निर्भर करती हैं जिन्हें ब्राउज़र आपके लिए अलग नहीं करते हैं: | **आयाम** | **ब्राउज़र आपको क्या देते हैं** | **आपको वास्तव में क्या चाहिए** | **उदाहरण** | | -------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | **ऑपरेशन संदर्भ** | `NotAllowedError` | क्या यह सशर्त UI, मोडल लॉगिन, मैन्युअल निर्माण, सशर्त निर्माण, या ऑटो-अपेंड था? | Android लॉगिन डिसमिस (अपेक्षित) और निर्माण विफलता (अप्रत्याशित) के लिए समान "अज्ञात त्रुटि" लौटाता है | | **समय** | कोई अवधि डेटा नहीं | तत्काल (`<1s`) बनाम उपयोगकर्ता कैंसल (1-15s) बनाम टाइमआउट (30s+) | 200ms = पर्यावरण अस्वीकृति; 5s = उपयोगकर्ता ने संवाद देखा और रद्द कर दिया; 35s = टाइमआउट | | **प्लेटफ़ॉर्म + ऑथेंटिकेटर** | सामान्य `error.name` | हर त्रुटि के लिए OS, ब्राउज़र, संस्करण, क्रेडेंशियल मैनेजर | Chrome पर "उपयोगकर्ता ने संवाद खारिज कर दिया" और Safari पर "ऑटोफिल अनुपलब्ध" दोनों `NotAllowedError` के रूप में सामने आते हैं | ### 12.2 Corbado का ऑब्ज़र्वेबिलिटी SDK क्या कैप्चर करता है यही वह समस्या है जिसे हल करने के लिए [Corbado का ऑब्ज़र्वेबिलिटी SDK](https://www.corbado.com/pricing) बनाया गया है। यह एक हल्का फ्रंटएंड एकीकरण है जो आपके मौजूदा पासकी कार्यान्वयन के शीर्ष पर बैठता है, किसी भी WebAuthn सर्वर और किसी भी IDP के साथ काम करता है, और स्वचालित रूप से सभी तीन आयामों के साथ हर WebAuthn त्रुटि को वर्गीकृत करता है: | **क्षमता** | **यह क्या करता है** | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **त्रुटि एट्रिब्यूशन** | हर समारोह प्रयास के साथ OS, OS संस्करण, ब्राउज़र, ब्राउज़र संस्करण और ऑथेंटिकेटर को कैप्चर करता है | | **ऑपरेशन मोड** | प्रत्येक त्रुटि को विशिष्ट ऑपरेशन (सशर्त UI, मोडल लॉगिन, मैन्युअल निर्माण, सशर्त निर्माण, ऑटो-अपेंड) से जोड़ता है ताकि एक ही `NotAllowedError` अलग-अलग मूल कारणों को हल करे | | **कार्रवाई शुरू होने से समय** | तत्काल अस्वीकृतियों, उपयोगकर्ता कैंसल और टाइमआउट को बिना अनुमान लगाए अलग करने के लिए समारोह की शुरुआत से अवधि रिकॉर्ड करता है | | **बुद्धिमान त्रुटि वर्गीकरण** | संपूर्ण त्रुटि संदर्भ (न केवल नाम) पर मिलान करता है, विविध **वातावरण** (OS, हार्डवेयर, सेटिंग्स) में सामान्यीकरण करता है। **CDA** बनाम लोकल जैसे विशिष्ट त्रुटि समूहों को प्राथमिकता देता है, और **अपेक्षित (उपयोगकर्ता निरस्त)** को **अप्रत्याशित (सिस्टम विफलता)** त्रुटियों से अलग करता है। | | **पासवर्ड मैनेजर विखंडन** | पता लगाता है कि क्रेडेंशियल मैनेजर एक्सटेंशन (Bitwarden, 1Password, LastPass) समारोहों को कब रोकते हैं और गैर-मानक प्रतिक्रियाएं देते हैं, एक्सटेंशन-कारण विफलताओं को प्लेटफ़ॉर्म विफलताओं से अलग करते हैं | यह **ऑब्ज़र्व** लेयर है: आपके कार्यान्वयन को बदले बिना, क्या हो रहा है इसकी दृश्यता। ### 12.3 डिबग करने के दो तरीके: टॉप-डाउन और बॉटम-अप 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](https://www.corbado.com/ai-analytics-assistant) त्रुटि डेटा और अपनाने के मेट्रिक्स दोनों में आपको प्राकृतिक भाषा में प्रश्न पूछने की अनुमति देकर दोनों को जोड़ता है। जो टीमें इन संकेतों पर कार्य करना चाहती हैं, वे **एडॉप्ट** में जा सकती हैं, जो स्वचालित रूप से समारोहों को गेट करने, नामांकन प्रॉम्प्ट को अनुकूलित करने और टूटी हुई पासकी स्थितियों को ठीक करने के लिए [पासकी इंटेलिजेंस](https://docs.corbado.com/corbado-connect/features/passkey-intelligence) जोड़ता है। विनियमित वातावरण या हाइपरस्केल तैनाती के लिए, **एंटरप्राइज़** सिंगल-टेनेंट होस्टिंग, SIEM एकीकरण और PSD2-अनुपालन कॉन्फ़िगरेशन जोड़ता है। ## 13. निष्कर्ष 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 का उपयोग करने पर विचार करें। ## अक्सर पूछे जाने वाले प्रश्न ### मैं उपयोगकर्ता द्वारा पासकी प्रॉम्प्ट को रद्द करने और डिवाइस में पासकी न होने के बीच अंतर कैसे बताऊं? वेब पर, ब्राउज़र गोपनीयता कारणों से दोनों मामलों को `NotAllowedError` में ढहा देते हैं, इसलिए आप उन्हें सीधे अलग नहीं कर सकते। एक प्रॉक्सी के रूप में समय का उपयोग करें: 1 सेकंड से कम की त्रुटि का आमतौर पर मतलब पर्यावरण अस्वीकृति या लापता क्षमता होता है, जबकि 1-15 सेकंड बताता है कि उपयोगकर्ता ने संवाद देखा और खारिज कर दिया। नेटिव iOS और Android ऐप पर, अनुरोध से पहले `preferImmediatelyAvailableCredentials` सेट करने से आपको कोई भी UI दिखाए जाने से पहले एक साफ "कोई क्रेडेंशियल नहीं" संकेत (iOS कोड 1005, Android `GetCredentialRequest`) मिलता है। ### मेरी WebAuthn त्रुटि दर इतनी अधिक क्यों है, भले ही अधिकांश उपयोगकर्ताओं के लिए पासकी काम कर रही हो? अनुकूलित बड़े पैमाने पर पासकी तैनाती में, दर्ज की गई 95% से अधिक WebAuthn त्रुटियां अपेक्षित उपयोगकर्ता गर्भपात हैं, सिस्टम विफलताएं नहीं हैं। "उपयोगकर्ता ने प्रॉम्प्ट खारिज कर दिया" को वास्तविक विफलताओं से अलग किए बिना कच्चे `error.name` की गिनती ट्रैक करने से त्रुटि मेट्रिक्स बढ़ जाते हैं और `NotAllowedError` वॉल्यूम के अंदर छिपे वास्तविक प्रतिगमन को मुखौटा बना देते हैं। अपनी गणनाओं को ऑपरेशन प्रकार से विभाजित करें और उपयोगकर्ता-कैंसल बकेट को `SecurityError`, `ConstraintError` और `DataError` जैसी अप्रत्याशित त्रुटियों से अलग से मानें। ### iOS पर ASAuthorizationError कोड 1005 का क्या अर्थ है और मुझे इसका उपयोग कैसे करना चाहिए? iOS कोड 1005 (`NotInteractive`) का अर्थ है कि डिवाइस पर कोई पासकी उपलब्ध नहीं थी जब `ASAuthorizationController` पर `preferImmediatelyAvailableCredentials` सेट किया गया था, और उपयोगकर्ता को कोई UI नहीं दिखाया गया था। यह साफ़ "इस डिवाइस पर कोई पासकी मौजूद नहीं है" संकेत है जो वेब ब्राउज़र गोपनीयता बाधाओं के कारण प्रदान नहीं कर सकते हैं। हमेशा संख्यात्मक कोड पर वर्गीकृत करें, `localizedDescription` पर नहीं, क्योंकि Apple के संदेशों को 30+ भाषाओं में स्थानीयकृत किया जाता है और OS संस्करणों में बदला जा सकता है। ### मुझे सशर्त निर्माण या ऑटो-ट्रिगर पासकी अपेंड प्रवाह के दौरान NotAllowedError को कैसे संभालना चाहिए? सशर्त निर्माण के दौरान, `NotAllowedError`, `AbortError` और `InvalidStateError` सभी अपेक्षित परिणाम हैं और इन्हें त्रुटियों के रूप में सामने लाने के बजाय चुपचाप अनदेखा किया जाना चाहिए। `NotAllowedError` इंगित करता है कि ऑटोफिल अनुपलब्ध है या पृष्ठ ने फोकस खो दिया है, जबकि `InvalidStateError` का अर्थ है कि प्रदाता में एक पासकी पहले से मौजूद है। कॉल का प्रयास करने से पहले, `conditionalCreate` समर्थन को सत्यापित करने के लिए `getClientCapabilities()` का उपयोग करें और अपनी त्रुटि गणनाओं को बढ़ाने से बचने के लिए दस्तावेज़ दृश्यता स्थिति की जांच करें। ### WebAuthn विफलताओं को वास्तव में डीबग करने योग्य बनाने के लिए मुझे error.name के साथ कौन सा संदर्भ लॉग करना चाहिए? ऑपरेशन प्रकार (सशर्त UI, मोडल लॉगिन, मैन्युअल निर्माण, सशर्त निर्माण या ऑटो-अपेंड), ऑपरेशन शुरू होने से त्रुटि तक का समय, OS संस्करण, ब्राउज़र संस्करण, हार्डवेयर मॉडल, क्या QR/हाइब्रिड UI दिखाई दिया और सर्वर-साइड लॉग के साथ जुड़ने के लिए एक सहसंबंध आईडी कैप्चर करें। चुनौती बेमेल, अमान्य हस्ताक्षर और क्रेडेंशियल न मिलने जैसी सर्वर सत्यापन विफलताओं को स्पष्ट संरचित कोड के रूप में लॉग किया जाना चाहिए, न कि क्लाइंट-साइड `DOMException` नामों के समान बकेट में मिश्रित किया जाना चाहिए। ये संकेत एक साथ बिना अनुमान लगाए कार्रवाई योग्य बकेट में अधिकांश त्रुटियों के वर्गीकरण की अनुमति देते हैं।