Frontend साक्षात्कार: आप Storage Access API के साथ एम्बेडेड लॉगिन कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और संदर्भ

एक आइडेंटिटी प्रोवाइडर कई ग्राहक साइटों पर एक iframe में एम्बेडेड है। साइन-इन किए गए यूज़र को अकाउंट की जानकारी दिखनी चाहिए, लेकिन ब्राउज़र थर्ड-पार्टी कुकीज़ को पार्टीशन या ब्लॉक कर सकते हैं। हर एम्बेड को एक साइलेंट ट्रैकिंग चैनल बनाए बिना Storage Access API का उपयोग करके एक फ्लो डिज़ाइन करें।

मान लें कि iframe अपने स्वयं के फर्स्ट-पार्टी पेज पर नेविगेट कर सकता है, टॉप-लेवल साइट iframe अनुमतियों को नियंत्रित करती है, और यूज़र प्रॉम्प्ट को अस्वीकार कर सकते हैं। उत्तर में सहमति, CSRF, फॉलबैक और लॉगआउट शामिल होना चाहिए।

साक्षात्कारकर्ता क्या जांचता है

• क्या आप जानते हैं कि स्टोरेज एक्सेस अनुमति-आधारित (permission-gated) और फ्रेम-स्कोप आधारित (frame-scoped) है, न कि एक यूनिवर्सल कुकी स्विच।
• क्या आप एक्सेस का अनुरोध करने से पहले यूज़र एक्टिवेशन और एक स्पष्ट प्रोडक्ट कारण की मांग करते हैं।
• क्या आप पार्टीशन्ड बूटस्ट्रैप स्थिति को अनपार्टीशन्ड सेशन स्थिति से अलग रखते हैं।
• क्या अस्वीकृति के बाद भी एक कार्यात्मक साइन्ड-आउट या रीडायरेक्ट-आधारित पथ उपलब्ध रहता है।

उत्तर देने से पहले स्पष्टीकरण प्रश्न

1. क्या विजेट को क्रॉस-साइट सेशन निरंतरता की आवश्यकता है, या क्या रीडायरेक्ट एक ऑथराइजेशन कोड वापस कर सकता है? रीडायरेक्ट एम्बेडेड कुकी एक्सेस के अनुरोध से बच सकता है।
2. क्या यूज़र ने आइडेंटिटी प्रोवाइडर को फर्स्ट-पार्टी के रूप में विज़िट किया है और उसकी कुकी सेट की है? कुछ ब्राउज़रों को एक्सेस देने से पहले उस संबंध की आवश्यकता होती है।
3. कौन से टॉप-लेवल ओरिजिन फ्रेम को एम्बेड कर सकते हैं? यह Permissions-Policy अनुमति सूची (allowlist) निर्धारित करता है।
4. सहमति से पहले क्या डेटा दिखाया जाता है? एक्सेस-पूर्व दृश्य से अकाउंट की पहचान लीक नहीं होनी चाहिए।

30-सेकंड उत्तर ढांचा

"मैं Storage Access API को एक यूज़र-मध्यस्थता क्षमता (user-mediated capability) के रूप में मानता हूँ, न कि फॉलबैक कुकी टॉगल के रूप में। iframe पार्टीशन्ड या अपारदर्शी स्थिति से शुरू होता है, केवल एक क्लिक के बाद अनुरोध करता है जो लाभ को स्पष्ट रूप से समझाता है, और लौटाए गए प्रॉमिस की जांच करता है। टॉप-लेवल साइट एक संकीर्ण Permissions-Policy अनुमति सूची भेजती है। अस्वीकृति पर, मैं फर्स्ट-पार्टी रीडायरेक्ट या साइन्ड-आउट अनुभव का उपयोग करता हूँ। स्थिति बदलने वाले प्रत्येक अनुरोध में अभी भी CSRF सुरक्षा होती है, और विजेट अपने सेशन को रद्द कर सकता है और उसी तटस्थ स्थिति में वापस आ सकता है।"

चरण-दर-चरण गहन विश्लेषण

1. स्थितियों और थ्रेट मॉडल को अलग करना

एक्सेस से पहले, iframe में पार्टीशन्ड स्टोरेज हो सकता है या कोई कुकी नहीं हो सकती है। इसे उस स्थिति से यूज़र की पहचान का अनुमान नहीं लगाना चाहिए। requestStorageAccess() सफल होने के बाद, एम्बेडेड दस्तावेज़ ब्राउज़र नीति के अनुसार अपनी अनपार्टीशन्ड फर्स्ट-पार्टी कुकीज़ तक पहुंच सकता है।

यह क्षमता दस्तावेज़ और एम्बेडिंग संदर्भ तक सीमित है। यह इस बात का प्रमाण नहीं है कि टॉप-लेवल साइट विश्वसनीय है, न ही यह ओरिजिन जांच, CSRF सुरक्षा, सहमति रिकॉर्ड और लॉगआउट सिमेंटिक्स का प्रतिस्थापन है।

2. यूज़र के इरादे के आधार पर अनुरोध को नियंत्रित करना

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

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

3. एम्बेडिंग सीमा को कॉन्फ़िगर करना

टॉप-लेवल प्रतिक्रिया नीति का स्वामित्व रखती है। केवल आइडेंटिटी ओरिजिन को अनुमति दें और केवल उन रूट्स पर जो विजेट को एम्बेड करते हैं:

Permissions-Policy: storage-access=(self "https://id.example")

iframe को अपेक्षित ओरिजिन और सैंडबॉक्स सेटिंग्स के साथ परोसा जाना चाहिए। सैंडबॉक्स किए गए फ्रेम को उपयुक्त same-origin क्षमता की आवश्यकता होती है, और ओरिजिन बेमेल होने पर इसे बंद (fail closed) होना चाहिए। नीति को एक अनुमति सूची के रूप में मानें, न कि प्रत्येक थर्ड-पार्टी को एक्सेस देने के तरीके के रूप में।

4. फर्स्ट-पार्टी और एम्बेडेड फ्लो स्थापित करना

यदि ब्राउज़र को फर्स्ट-पार्टी इंटरैक्शन की आवश्यकता होती है, तो विजेट आइडेंटिटी ओरिजिन पर एक फर्स्ट-पार्टी पेज खोलता है। यूज़र वहां साइन इन करता है, आइडेंटिटी प्रोवाइडर अपनी फर्स्ट-पार्टी कुकी सेट करता है, और एक अल्पकालिक, ओरिजिन-बाउंड परिणाम एम्बेड पर लौटता है। यह परिणाम URL में पुन: प्रयोज्य बियरर टोकन नहीं होना चाहिए।

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

5. अस्वीकृति, लॉगआउट और मापन को डिज़ाइन करना

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

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

उच्च गुणवत्ता वाला नमूना उत्तर

मैं एक अज्ञात iframe के साथ शुरुआत करूँगा जो केवल एक साइन-इन विकल्प रेंडर करता है। यूज़र क्लिक के बाद, यह स्टोरेज एक्सेस का अनुरोध करता है और अस्वीकृति को स्पष्ट रूप से संभालता है। एम्बेडिंग पेज आइडेंटिटी ओरिजिन के लिए एक संकीर्ण Permissions-Policy अनुमति सूची भेजता है। यदि किसी ब्राउज़र को फर्स्ट-पार्टी इंटरैक्शन की आवश्यकता होती है, तो मैं आइडेंटिटी साइट पर रीडायरेक्ट करता हूँ, वहां उसका सेशन स्थापित करता हूँ, और URL में बियरर टोकन डाले बिना एक ओरिजिन-बाउंड परिणाम लौटाता हूँ।

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

सामान्य गलतियाँ

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

फॉलो-अप प्रश्न और उत्तर

क्या पार्टीशन्ड कुकीज़ Storage Access API की जगह ले सकती हैं?

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

यदि iframe सैंडबॉक्स किया गया हो तो क्या होगा?

सत्यापित करें कि सैंडबॉक्स फ्लो के लिए आवश्यक ओरिजिन और क्षमता को सुरक्षित रखता है। यदि यह ओरिजिन को अपारदर्शी बनाता है या API को ब्लॉक करता है, तो इसे बंद (fail closed) करें और फर्स्ट-पार्टी रीडायरेक्ट का उपयोग करें। केवल एक एम्बेड को काम करने के लिए सैंडबॉक्स को वैश्विक स्तर पर कमजोर न करें।

क्या दी गई स्टोरेज एक्सेस CSRF जोखिम को समाप्त करती है?

नहीं। एक्सेस के बाद iframe कुकीज़ भेज सकता है, इसलिए स्थिति बदलने वाले एंडपॉइंट्स को अभी भी CSRF सुरक्षा, ओरिजिन सत्यापन, जहां लागू हो SameSite कुकी सेटिंग्स और ऑथराइजेशन की आवश्यकता होती है। स्टोरेज अनुमति पहुंच क्षमता को बदलती है, अनुरोध के इरादे को नहीं।