फ़्रंटएंड इंटरव्यू: स्टोरेज पार्टिशनिंग और CHIPS के तहत आप एक उपयोगी थर्ड-पार्टी एम्बेड कैसे डिज़ाइन करते हैं?

1. सवाल और संदर्भ

आप कई मर्चेंट साइटों द्वारा एम्बेड किए गए एक सपोर्ट विजेट का रखरखाव करते हैं। इसे असंबंधित टॉप-लेवल साइटों पर एक ही उपयोगकर्ता को लिंक किए बिना प्रत्येक मर्चेंट के लिए एक विज़िटर सत्र याद रखना चाहिए। ब्राउज़र टॉप-लेवल साइट और थर्ड-पार्टी ओरिजिन द्वारा कुकीज़, localStorage, कैश और नेटवर्क स्थिति को अलग (आइसोलेट) कर सकते हैं।

2. इंटरव्यूअर क्या मूल्यांकन कर रहा है

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

3. उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

1. टॉप-लेवल साइटों पर क्या साझा किया जाना चाहिए, और क्या साझा पहचान (शेयर्ड आइडेंटिटी) वास्तव में आवश्यक है?
2. क्या प्रत्येक साइट की अपनी टेनेंट, उपयोगकर्ता और सत्र सीमा (सेशन बाउंड्री) है?
3. क्या उपयोगकर्ता अधिकृत करने के लिए एक बार क्लिक कर सकता है, या विजेट को बिना किसी इंटरैक्शन के लोड होना चाहिए?
4. कौन से ब्राउज़र और एम्बेडिंग मोड मायने रखते हैं: iframe, पॉपअप, या टॉप-लेवल नेविगेशन?

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

डेटा सीमा, डिफ़ॉल्ट, अधिकृत अपवाद, फ़ॉलबैक और सत्यापन के साथ उत्तर दें।

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

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

चरण 1: पार्टिशन की और डेटा श्रेणियों को परिभाषित करें

Google Privacy Sandbox थर्ड-पार्टी स्टोरेज और संचार को पार्टिशन द्वारा आइसोलेटेड के रूप में वर्णित करता है। MDN स्टेट पार्टिशनिंग को ब्राउज़र प्राइवेसी प्रयास के रूप में वर्णित करता है जो क्रॉस-साइट ट्रैकिंग को कम करता है। डेटा को मर्चेंट-लोकल सत्र स्थिति, सार्वजनिक रूप से कैश करने योग्य संपत्तियों (एसेट्स), या ऐसी खाता स्थिति के रूप में वर्गीकृत करें जिसे वास्तव में क्रॉस-साइट पहचान की आवश्यकता है। पहली श्रेणी को पार्टिशनिंग को बायपास नहीं करना चाहिए।

चरण 2: प्रति-साइट सत्रों के लिए CHIPS का उपयोग करें

CHIPS थर्ड-पार्टी कुकी को पार्टिशन्ड स्टोरेज में ऑप्ट-इन करने की अनुमति देता है। रिस्पॉन्स में Partitioned; Secure का उपयोग होना चाहिए और ब्राउज़र की अन्य कुकी सुरक्षा आवश्यकताओं को पूरा करना चाहिए। समान विजेट ओरिजिन फिर मर्चेंट A और मर्चेंट B पर अलग-अलग कुकी जार प्राप्त करता है, इसलिए सपोर्ट संदर्भ स्वाभाविक रूप से साइटों पर मर्ज नहीं होता है। CHIPS प्रति-टॉप-लेवल-साइट स्थिति प्रदान करता है, साझा क्रॉस-साइट लॉगिन नहीं।

चरण 3: क्रॉस-साइट पहचान के लिए स्पष्ट प्राधिकरण डिज़ाइन करें

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

चरण 4: अनुकूलता और प्राइवेसी मैट्रिक्स बनाएं

CHIPS का समर्थन करने वाले ब्राउज़र, पार्टिशन्ड-कुकी समर्थन के बिना ब्राउज़र, अस्वीकृत स्टोरेज एक्सेस, साइट-डेटा क्लियरिंग, एक साथ खुली कई टॉप-लेवल साइटों, और iframe प्रतिस्थापन या नेविगेशन के बाद पुनः लोड का परीक्षण करें। कुकी आइसोलेशन, सत्र पुनर्प्राप्ति, बार-बार आने वाले प्रॉम्प्ट्स, और क्या स्टेटलेस मोड अभी भी मुख्य क्रिया को पूरा करता है, इसका दावा (assert) करें।

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

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

>

डिफ़ॉल्ट पाथ पर, विजेट सर्वर एक Partitioned; Secure कुकी सेट करता है। ब्राउज़र टॉप-लेवल साइट और विजेट ओरिजिन से एक स्वतंत्र स्टोरेज पार्टिशन बनाता है, इसलिए मर्चेंट A पर मौजूद सत्र मर्चेंट B पर अनुपस्थित रहता है। स्टैटिक स्क्रिप्ट और छवियां सामान्य कैशिंग का उपयोग कर सकती हैं, लेकिन पहचान को ऐसी स्थिति में नहीं रखा जाता है जिसे विभिन्न साइटों पर पढ़ा जा सके।

>

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

7. सामान्य विफलता मोड

• CHIPS को पार्टिशन्ड स्थिति के बजाय एक साझा क्रॉस-साइट कुकी के रूप में मानना।
• सभी स्थिति को अनपार्टिशन्ड एक्सेस में ले जाना, जिससे ट्रैकिंग और विफलता का दायरा बढ़ जाता है।
• केवल Chrome पर चर्चा करना और Firefox, Safari, या क्षमता-पहचान विफलताओं को छोड़ देना।
• उपयोगकर्ता की कार्रवाई, स्पष्टीकरण, या इनकार फ़ॉलबैक के बिना iframe लोड पर चुपचाप एक्सेस का अनुरोध करना।
• एक दीर्घकालिक (लॉन्ग-लिव्ड) टोकन को सीधे रिटर्न URL में डालना, जिससे यह लॉग, इतिहास या रेफ़रर्स के संपर्क में आ जाता है।

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

फॉलो-अप 1: उपयोगकर्ता आईडी को टॉप-लेवल साइट के URL में क्यों न रखें?

URL लॉग, इतिहास, एनालिटिक्स सिस्टम और रेफ़रर्स में जा सकते हैं। एक अल्पकालिक वन-टाइम कोड का उपयोग करें और इसे सर्वर-साइड पर एक सीमित सत्र के लिए एक्सचेंज करें।

फॉलो-अप 2: एक CHIPS कुकी उपयोगकर्ता को साइन आउट कब दिखा सकती है?

एक नई टॉप-लेवल साइट पर पहली विज़िट में एक नई पार्टिशन्ड कुकी होती है। यह जानबूझकर किया गया आइसोलेशन है। दूसरी साइट की कुकी को पढ़ने का प्रयास करने के बजाय एक स्पष्ट टॉप-लेवल साइन-इन फ़्लो प्रदान करें।

फॉलो-अप 3: जब Storage Access API अस्वीकृत हो जाए तो आप मुख्य कार्यक्षमता को कैसे सुरक्षित रखते हैं?

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