प्रॉम्ट और दायरा
एक फ़ाइल-अपलोड API को क्लाइंट्स को यह सत्यापित करने की अनुमति देनी चाहिए कि HTTP सामग्री को किसी गेटवे या कैश द्वारा फिर से नहीं लिखा (rewritten) गया है। RFC 9530 के आधार पर, Content-Digest, Repr-Digest, और Want-Repr-Digest के उपयोग को डिज़ाइन करें, और TLS, डिजिटल सिग्नेचर और पुनः प्रयासों (retries) के साथ उनकी सीमाओं की व्याख्या करें।
यह प्रश्न यह परीक्षण करता है कि क्या आप किसी डाइजेस्ट को सही HTTP लेयर से जोड़ सकते हैं: Content-Digest वास्तविक मैसेज सामग्री को कवर करता है, Repr-Digest चयनित रिप्रेजेंटेशन (representation) का वर्णन करता है, और Want-Repr-Digest रिप्रेजेंटेशन डाइजेस्ट के लिए रिसीवर की प्राथमिकता को व्यक्त करता है। डाइजेस्ट सामग्री की अखंडता (integrity) की जाँच करता है; यह अपने आप में यह साबित नहीं करता कि संदेश किसने भेजा है।
इंटरव्यूअर क्या जांच रहा है
मैसेज सामग्री और रिप्रेजेंटेशन के बीच अंतर, सुरक्षित एल्गोरिदम चयन, रिक्वेस्ट और रिस्पॉन्स नेगोशिएशन, प्रॉक्सी और कम्प्रेशन सीमाएं, स्ट्रीमिंग कम्प्यूटेशन, डाइजेस्ट-विफलता स्टेट मशीन, और प्रमाणीकरण (authentication), TLS, पुनः प्रयासों (retries) और आइडेम्पोटेंसी के साथ डाइजेस्ट के सही संयोजन को कवर करें।
30 सेकंड का उत्तर
"मैं सबसे पहले उस ऑब्जेक्ट और बाइट सीमा को परिभाषित करता हूँ जिसे सत्यापित किया जा रहा है। अपलोड क्लाइंट Content-Digest की गणना करता है, और सर्वर प्राप्त संदेश को स्ट्रीम करते समय इसे सत्यापित करता है। सर्वर Repr-Digest लौटा सकता है, जिसे क्लाइंट अंतिम रिप्रेजेंटेशन के विरुद्ध जांचता है। Want-Repr-Digest एल्गोरिदम प्राथमिकताओं को संप्रेषित करता है; सर्वर केवल एक अनुमत मजबूत एल्गोरिदम चुनता है और परिणाम रिकॉर्ड करता है। बेमेल होने पर डिलीवरी या पर्सीस्टेंस रुक जाती है। प्रेषक प्रमाणीकरण अभी भी TLS, HTTP Message Signatures, या एक्सेस टोकन से ही आता है।"
चरण-दर-चरण समाधान
चरण 1: संरक्षित ऑब्जेक्ट को परिभाषित करें
बताएं कि लक्ष्य स्थानांतरित मैसेज सामग्री है या कंटेंट नेगोशिएशन के बाद का रिप्रेजेंटेशन। Content-Digest वास्तविक मैसेज सामग्री पर लागू होता है; Repr-Digest चयनित रिप्रेजेंटेशन का वर्णन करता है। एक रिप्रेजेंटेशन डाइजेस्ट ट्रांसकोडिंग के बाद एक अलग बाइट अनुक्रम को मान्य नहीं कर सकता है।
चरण 2: डाइजेस्ट एल्गोरिदम का चयन करें
वर्तमान में स्वीकृत एल्गोरिदम जैसे SHA-256 या SHA-512 वाली अनुमति सूची (allowlist) का उपयोग करें, और MD5 या SHA-1 जैसे पुराने विकल्पों को अस्वीकार करें। स्ट्रक्चर्ड फ़ील्ड को पार्स करते समय, डुप्लिकेट एल्गोरिदम, अज्ञात पैरामीटर और विकृत एन्कोडिंग को अस्वीकार करें ताकि विभिन्न लाइब्रेरी एक ही मान की अलग-अलग व्याख्या न कर सकें।
चरण 3: रिक्वेस्ट्स को सत्यापित करें
अपलोड क्लाइंट अंतिम मैसेज बाइट्स पर Content-Digest की गणना करता है। सर्वर पढ़ते समय इसकी गणना करता है और मैसेज समाप्त होने के बाद ही तुलना करता है। बेमेल होने पर ऑब्जेक्ट कमिट और इवेंट प्रकाशन रुक जाता है; आंशिक आउटपुट को कभी भी सफलता नहीं माना जाता है। बड़े अपलोड को मेमोरी में बफर करने के बजाय स्ट्रीम किया जाना चाहिए।
चरण 4: रिस्पॉन्स को सत्यापित करें
सर्वर रिस्पॉन्स में Repr-Digest भेज सकता है। क्लाइंट नेगोशिएट किए गए नियम के अनुसार डिकोड किए गए चयनित रिप्रेजेंटेशन पर डाइजेस्ट की गणना करता है। यदि कम्प्रेशन शामिल है, तो प्रोटोकॉल को यह बताना होगा कि डाइजेस्ट कंप्रेस्ड मैसेज को कवर करता है या असम्पीडित (uncompressed) रिप्रेजेंटेशन को; क्लाइंट्स को उन लेयर्स को आपस में नहीं मिलाना चाहिए।
चरण 5: Want-Repr-Digest का उपयोग करें
क्लाइंट एल्गोरिदम प्राथमिकताओं और भार (weights) के साथ Want-Repr-Digest भेज सकता है। सर्वर इसे पूरा कर सकता है, दूसरा अनुमत एल्गोरिदम चुन सकता है, या रिस्पॉन्स फ़ील्ड को छोड़ सकता है। क्लाइंट को "डाइजेस्ट प्रदान नहीं किया गया" और "डाइजेस्ट बेमेल" के बीच अंतर करना चाहिए; अनुपस्थिति सफल सत्यापन नहीं है।
चरण 6: प्रॉक्सी और कैश को संभालें
कैश हिट के लिए अभी भी वर्तमान रिप्रेजेंटेशन से मेल खाने वाले डाइजेस्ट की आवश्यकता होती है। यदि कोई गेटवे सामग्री को पुनः कंप्रेस, ट्रांसकोड या संयोजित करता है, तो उसे प्रासंगिक डाइजेस्ट की पुनर्गणना करनी होगी; अपस्ट्रीम फ़ील्ड की नकल करने से गलत परिणाम उत्पन्न होता है। डाइजेस्ट के कवर किए गए बाइट्स के बाहर किसी फ़ील्ड को फिर से लिखने से डाइजेस्ट अपने आप नहीं टूटता, लेकिन यह सिग्नेचर या ऑथराइजेशन सेमेंटिक्स को बदल सकता है।
चरण 7: प्रमाणीकरण और रीप्ले सुरक्षा को संयोजित करें
एक डाइजेस्ट बाइट संबंध को साबित करता है, प्रेषक की पहचान को नहीं, और यह किसी वैध संदेश को दोबारा भेजे जाने से नहीं रोकता है। प्रेषक प्रमाणीकरण के लिए TLS, HTTP Message Signatures, या टोकन का उपयोग करें। डुप्लिकेट शुल्कों को रोकने के लिए नॉन्स (nonce), टाइम विंडो और व्यावसायिक आइडेम्पोटेंसी की का उपयोग करें। डाइजेस्ट मान कोई ऑथराइजेशन क्रेडेंशियल नहीं है।
चरण 8: विफलताओं और ऑब्जर्वेबिलिटी को परिभाषित करें
बेमेल, अस्वीकृत एल्गोरिदम, विकृत फ़ील्ड और अनुपलब्ध फ़ील्ड के लिए अलग मेट्रिक्स और एरर क्लासेज को प्रदर्शित करें। अपलोड सत्यापन विफल होने के बाद अस्थायी ऑब्जेक्ट्स को साफ करें; असत्यापित कैश्ड रिस्पॉन्स को त्यागें और पुनः प्रयास नीति (retry policy) को ट्रिगर करें। एल्गोरिदम, रिक्वेस्ट ID, आकार और विफलता वर्ग को लॉग करें, कभी भी संवेदनशील सामग्री या संपूर्ण पेलोड को लॉग न करें।
ट्रेड-ऑफ और सीमाएं
Content-Digest या Repr-Digest
Content-Digest यह सत्यापित करने के लिए उपयुक्त है कि इस HTTP संदेश ने वास्तव में क्या स्थानांतरित किया है। Repr-Digest कैश, कंटेंट नेगोशिएशन और रिसोर्स रिप्रेजेंटेशन सत्यापन के लिए उपयुक्त है। वे एक साथ सह-अस्तित्व में रह सकते हैं, लेकिन प्रोटोकॉल को बाइट सीमाओं और डिकोडिंग क्रम का दस्तावेजीकरण करना होगा।
डाइजेस्ट या डिजिटल सिग्नेचर
डाइजेस्ट सस्ते होते हैं और ट्रांसिट या स्टोरेज में बदलाव का पता लगाते हैं। डिजिटल सिग्नेचर इसके अतिरिक्त एक की-होल्डर को प्रमाणित करते हैं और क्रॉस-सिस्टम सत्यापन का समर्थन करते हैं। सामग्री अखंडता को विधि (method) और लक्ष्य (target) से जोड़ने के लिए एक सिग्नेचर डाइजेस्ट फ़ील्ड को कवर कर सकता है, लेकिन डाइजेस्ट में स्वयं कोई पहचान गुण नहीं होता है।
फेल क्लोज्ड (Fail closed) या डिग्रेड
पेमेंट्स, सॉफ्टवेयर पैकेज और विनियमित अभिलेखागार को गायब या बेमेल डाइजेस्ट को अस्वीकार कर देना चाहिए। वैकल्पिक डाइजेस्ट वाला एक साधारण स्थिर संसाधन चेतावनी रिकॉर्ड करने के बाद जारी रह सकता है, लेकिन कॉलर को यह पता होना चाहिए कि अखंडता सत्यापित नहीं की गई थी; इसे चुपचाप विश्वसनीय के रूप में चिह्नित नहीं किया जाना चाहिए।
विफलता अभ्यास (Failure drills) और विकास
गेटवे रिस्पॉन्स को पुनः कंप्रेस करता है
एक गेटवे से कम्प्रेशन बदलवाएं, फिर सत्यापित करें कि क्लाइंट अभी भी प्रोटोकॉल-परिभाषित रिप्रेजेंटेशन लेयर को हैश करता है। यदि गेटवे ने कवर की गई लेयर को बदल दिया है, तो उसे एक नया फ़ील्ड जनरेट करना होगा।
अपलोड के दौरान एक बाइट बदलता है
प्रॉक्सी में एक बाइट बदलें और सत्यापित करें कि सर्वर ऑब्जेक्ट को कमिट करने से पहले Content-Digest बेमेल की रिपोर्ट करता है, फिर अस्थायी डेटा और डाउनस्ट्रीम इवेंट्स को हटा देता है।
एल्गोरिदम डाउनग्रेड या अनुपलब्ध फ़ील्ड
एक लीगेसी एल्गोरिदम वाली प्राथमिकता भेजें और सत्यापित करें कि सर्वर अस्वीकृत विकल्प को अस्वीकार करता है। Repr-Digest को हटाएं और पुष्टि करें कि क्लाइंट सफलता शाखा के बजाय "असत्यापित" शाखा में जाता है।
सामान्य गलतियाँ और फॉलो-अप
गलती 1: डाइजेस्ट को प्रमाणीकरण मानना
फॉलो-अप: क्या कोई हमलावर अपनी सामग्री के लिए डाइजेस्ट की पुनर्गणना कर सकता है? हाँ। प्रेषक को प्रमाणित करने के लिए अभी भी TLS, सिग्नेचर या टोकन की आवश्यकता होती है।
गलती 2: कम्प्रेशन और रिप्रेजेंटेशन लेयर्स की अनदेखी करना
फॉलो-अप: क्या एक अपस्ट्रीम डाइजेस्ट को पुनः कंप्रेस किए गए रिस्पॉन्स में कॉपी किया जा सकता है? केवल तभी जब कवर की गई बाइट लेयर अपरिवर्तित हो; अन्यथा इसे पुनर्गणित किया जाना चाहिए।
गलती 3: अनुपलब्ध फ़ील्ड को सत्यापित मानना
फॉलो-अप: क्या होगा यदि सर्वर अनुरोधित डाइजेस्ट को छोड़ देता है? परिणाम को असत्यापित के रूप में चिह्नित करें या नीति के अनुसार इसे अस्वीकार करें; चूक (omission) कोई मिलान नहीं है।
गहरे फॉलो-अप और मॉडल उत्तर
अपलोड रिक्वेस्ट Content-Digest का उपयोग क्यों कर सकती है?
प्रेषक ट्रांसमिशन से पहले या स्ट्रीम पूरा होने पर डाइजेस्ट प्रदान कर सकता है, जिससे रिसीवर को पर्सीस्टेंस से पहले बाइट्स को सत्यापित करने की अनुमति मिलती है। बड़े ऑब्जेक्ट्स को बफर करने के बजाय वृद्धिशील (incrementally) रूप से हैश किया जाना चाहिए।
क्या डाइजेस्ट फ़ील्ड्स रीप्ले सुरक्षा हैं?
नहीं। वही वैध संदेश दोबारा भेजा जा सकता है। रीप्ले सुरक्षा के लिए टाइम विंडो, नॉन्स, सिग्नेचर कवरेज और व्यावसायिक आइडेम्पोटेंसी स्थिति की आवश्यकता होती है।
क्या किसी प्रॉक्सी को अपस्ट्रीम डाइजेस्ट हटा देना चाहिए?
केवल तभी जब उसने कवर किए गए बाइट्स को बदल दिया हो और वह फ़ील्ड की पुनर्गणना नहीं कर सकता हो, उसे इसे हटा देना चाहिए या अनुपयोगी के रूप में चिह्नित करना चाहिए। यदि वह पुनर्गणना कर सकता है, तो उसे अंतिम संदेश या रिप्रेजेंटेशन के लिए एक मान जनरेट करना चाहिए और जिम्मेदारी की सीमा का दस्तावेजीकरण करना चाहिए।