प्रॉम्प्ट और दायरा
प्रोडक्ट सर्वर-साइड स्टेट को कम करने के लिए यूज़र के WebAuthn क्रेडेंशियल के साथ एक छोटा एन्क्रिप्टेड कॉन्फ़िगरेशन बाइंड करना चाहता है। बताएं कि largeBlob कब उपयुक्त होता है, रजिस्ट्रेशन और ऑथेंटिकेशन में क्या अंतर है, क्लाइंट परिणामों की जांच कैसे करता है, और असमर्थित डिवाइसेस पर लॉगिन और डेटा सटीकता कैसे बनी रहती है।
इंटरव्यूअर क्या जांच रहा है
- क्या आप जानते हैं कि largeBlob एक क्रेडेंशियल से जुड़ा ओपेक (opaque) डेटा है, न कि सामान्य क्लाइंट स्टोरेज।
- क्या आप रजिस्ट्रेशन
supportको ऑथेंटिकेशनreadऔरwriteइनपुट्स और आउटपुट्स से अलग पहचानते हैं। - क्या आप ऑथेंटिकेटर क्षमता, डिस्कवरेबल क्रेडेंशियल्स, और एक-क्रेडेंशियल राइट बाधा (one-credential write constraint) को ध्यान में रखते हैं।
- क्या आप क्षमता का पता लगाने (capability detection), सर्वर बैकअप, प्राइवेसी, और विफलता फ़ॉलबैक को डिज़ाइन करते हैं।
स्पष्टीकरण के लिए प्रश्न
- क्या डेटा का इस क्रेडेंशियल के साथ जाना अनिवार्य है, या सर्वर डेटाबेस और IndexedDB पर्याप्त हैं?
- आकार, गोपनीयता, पुनर्प्राप्ति (recoverability), और क्रॉस-डिवाइस आवश्यकताएं क्या हैं?
- क्या लक्षित ऑथेंटिकेटर largeBlob का समर्थन करता है, और क्या क्रेडेंशियल डिस्कवरेबल है?
- विफल राइट, खोए हुए क्रेडेंशियल, या डिवाइस परिवर्तन के बाद सिस्टम कैसे पुनर्प्राप्त होता है?
30-सेकंड का उत्तर
मैं largeBlob को प्राइमरी स्टोरेज के रूप में नहीं, बल्कि एक वैकल्पिक ऑथेंटिकेटर क्षमता के रूप में मानूँगा। रजिस्ट्रेशन के दौरान support: preferred का अनुरोध करें और supported का निरीक्षण करें; ऑथेंटिकेशन के दौरान या तो read या write का उपयोग करें, राइट के लिए ठीक एक क्रेडेंशियल को लक्षित करें, और blob या written की जांच करें। डेटा को एन्क्रिप्ट और सीमित करें तथा एक पुनर्प्राप्ति योग्य सर्वर कॉपी रखें। असमर्थित क्षमता, क्षमता सीमा, या राइट विफलता की स्थिति में लॉगिन को ब्लॉक किए बिना या किसी अप्रमाणित राइट को सफल माने बिना सर्वर स्टेट पर फ़ॉलबैक होना चाहिए।
चरण-दर-चरण डिज़ाइन
1. सही डेटा सीमा चुनें
स्पेसिफिकेशन largeBlob को एक क्रेडेंशियल से जुड़े ओपेक डेटा के रूप में परिभाषित करता है। यह छोटे क्रेडेंशियल-बाउंड कॉन्फ़िगरेशन या की मटीरियल के लिए उपयुक्त है, न कि यूज़र प्रोफाइल, क्रॉस-क्रेडेंशियल सिंक्रोनाइज़ेशन, या किसी ऑब्जेक्ट डेटाबेस के लिए। ऑथेंटिकेटर्स की क्षमता सीमित होती है, इसलिए सर्वर को रिकवरी जानकारी बनाए रखनी चाहिए।
2. रजिस्ट्रेशन का उपयोग केवल क्षमता का पता लगाने के लिए करें
रजिस्ट्रेशन एक्सटेंशन largeBlob: { support: "preferred" } या required को स्वीकार करता है। supported यह बताता है कि क्या बनाया गया क्रेडेंशियल एक ब्लॉब को स्टोर कर सकता है; रजिस्ट्रेशन के दौरान कोई ब्लॉब राइट नहीं किया जाता है। required के साथ, असमर्थित ऑथेंटिकेटर्स को बाहर कर दिया जाता है, इसलिए इसे अनिवार्य बनाने से पहले कम्पैटिबिलिटी लागत का आकलन करें।
3. ऑथेंटिकेशन के दौरान रीड्स और राइट्स को अलग करें
ऑथेंटिकेशन read: true का अनुरोध कर सकता है या write प्रदान कर सकता है; दोनों की आपूर्ति करने पर विफलता मिलती है। राइट के लिए आवश्यक है कि allowCredentials में ठीक एक क्रेडेंशियल हो, और सफलता की रिपोर्ट written द्वारा दी जाती है। blob सदस्य केवल एक सफल रीड के बाद ही मौजूद होता है, न कि केवल इसलिए कि एक्सटेंशन ऑब्जेक्ट मौजूद है।
4. प्राइवेसी, रिकवरी और फ़ॉलबैक डिज़ाइन करें
ऑथेंटिकेटर डेटा ओपेक होता है, यह एप्लिकेशन द्वारा स्वचालित रूप से एन्क्रिप्टेड नहीं होता है। क्लाइंट और सर्वर को एन्क्रिप्शन, वर्ज़निंग और इंटीग्रिटी चेक प्रदान करने चाहिए। यदि क्रेडेंशियल अनुपलब्ध है, डिवाइस में समर्थन की कमी है, क्षमता अपर्याप्त है, या यूज़र अस्वीकार करता है, तो सर्वर कॉपी का उपयोग करें। क्षमता और परिणाम को लॉग करें, ब्लॉब सामग्री को कभी नहीं।
मॉडल उच्च-गुणवत्ता वाला उत्तर
मैं सर्वर-साइड स्टेट के प्रतिस्थापन के रूप में largeBlob का उपयोग नहीं करूँगा। यह एक छोटे ओपेक मान को एक WebAuthn क्रेडेंशियल से बाइंड करने के लिए उपयोगी है। रजिस्ट्रेशन के दौरान मैं support: preferred का अनुरोध करूँगा और supported का निरीक्षण करूँगा; ऑथेंटिकेशन के दौरान मैं read या write चुनूँगा, राइट के लिए एक क्रेडेंशियल को लक्षित करूँगा, और blob या written की जांच करूँगा। एप्लिकेशन एन्क्रिप्शन, वर्ज़निंग और इंटीग्रिटी का स्वामित्व रखता है, जबकि सर्वर एक रिकवरेबल कॉपी रखता है। असमर्थित ऑथेंटिकेटर्स, डिस्कवरेबल-क्रेडेंशियल बाधाएं, क्षमता त्रुटियां, राइट विफलताएं, और डिवाइस परिवर्तन ऑथेंटिकेशन को ब्लॉक किए बिना सर्वर स्टेट पर फ़ॉलबैक हो जाते हैं। मैं इस सुविधा को केवल तभी अनिवार्य करूँगा जब उत्पाद कम कम्पैटिबिलिटी स्वीकार करता हो और उसके पास एक माइग्रेशन योजना हो। यह लॉगिन या रिकवरी को इस पर निर्भर किए बिना ऑथेंटिकेटर स्टोरेज का उपयोग करता है।
सामान्य गलतियाँ
- largeBlob को IndexedDB, कुकी, या असीमित क्लाउड-सिंक्रोनाइज़्ड स्टोरेज मानना।
- यह मान लेना कि रजिस्ट्रेशन के दौरान एक ब्लॉब लिखा जा सकता है।
readऔरwriteको एक साथ आपूर्ति करना या राइट के लिए कई क्रेडेंशियल्स का नाम देना।supported,blob, याwrittenके बजाय केवल यह जांचना कि एक्सटेंशन ऑब्जेक्ट मौजूद है।- एप्लिकेशन एन्क्रिप्शन के बिना एक ओपेक ब्लॉब में संवेदनशील डेटा लिखना।
- जब कोई ऑथेंटिकेटर समर्थन नहीं करता है, तो सर्वर पर फ़ॉलबैक करने के बजाय लॉगिन को ब्लॉक करना।
फॉलो-अप प्रश्न और उत्तर
आप preferred बनाम required का चयन कैसे करते हैं?
preferred एक असमर्थित ऑथेंटिकेटर और फ़ॉलबैक की अनुमति देता है; required इसे बाहर कर देता है। जब तक कि प्रोडक्ट कम कवरेज स्वीकार न करे और वास्तव में इस क्षमता पर निर्भर न हो, तब तक preferred को प्राथमिकता दें।
एक राइट को ठीक एक क्रेडेंशियल को ही लक्षित क्यों करना चाहिए?
अपडेट किए जा रहे क्रेडेंशियल की पहचान करने के लिए स्पेसिफिकेशन एकल allowCredentials लक्ष्य का उपयोग करता है। एकाधिक उम्मीदवार एक असमर्थित-ऑपरेशन विफलता (unsupported-operation failure) उत्पन्न करते हैं, इसलिए एप्लिकेशन को पहले यूज़र के क्रेडेंशियल को हल करना होगा।
डिवाइस-माइग्रेशन योजना क्या है?
ब्लॉब को एक वैकल्पिक कैश या की कॉपी के रूप में मानें और सर्वर पर रिकवरी मटीरियल रखें। एक नया डिवाइस पुन: रजिस्ट्रेशन या ऑथेंटिकेशन के माध्यम से सर्वर स्टेट प्राप्त करता है; यह न मानें कि ऑथेंटिकेटर ब्लॉब डिवाइसेस में सिंक्रोनाइज़ होता है।