प्रश्न और कार्यक्षेत्र (Scope)
आप एक डैशबोर्ड के ओनर हैं जो कॉल्स के लिए meet.example, प्लेबैक के लिए video.example, और कई विज्ञापन फ्रेम्स को एम्बेड करता है। मीटिंग फ्रेम को microphone और camera की आवश्यकता है; वीडियो फ्रेम को fullscreen की आवश्यकता है; विज्ञापनों को इनमें से किसी भी फीचर की आवश्यकता नहीं है। पेज HTTPS है, फ्रेम ओरिजिन ज्ञात हैं, और जब पॉलिसी इसकी अनुमति देती है तब भी ब्राउज़र को मीडिया सहमति के लिए उपयोगकर्ता से पूछना आवश्यक है।
कार्यक्षेत्र ब्राउज़र-साइड पॉलिसी कंपोज़िशन और डायग्नोसिस है। ऑथेंटिकेशन, CSP, और सर्वर ऑथराइजेशन अलग नियंत्रण बने रहेंगे। मान लें कि रिस्पांस हेडर डैशबोर्ड सर्वर द्वारा सेट किया गया है और प्रत्येक क्रॉस-ओरिजिन फ्रेम में एक स्पष्ट allow एट्रिब्यूट है।
इंटरव्यूअर क्या टेस्ट कर रहा है
इंटरव्यूअर यह देखना चाहता है कि क्या आप तीन गेट्स को अलग करते हैं: रिस्पांस पॉलिसी, फ्रेम डेलिगेशन, और उपयोगकर्ता की रनटाइम अनुमति। केवल एक हेडर अनुमति सूची (allowlist) किसी क्रॉस-ओरिजिन फ्रेम को एक्सेस नहीं देती है, और एक allow एट्रिब्यूट उस हेडर को चौड़ा (widen) नहीं कर सकता जो फीचर को अस्वीकार करता है।
वे यह भी परीक्षण करते हैं कि क्या आप वाइल्डकार्ड की सुविधा से बचते हैं। एक मजबूत उत्तर संवेदनशील फीचर्स के लिए () से शुरू होता है, सटीक ओरिजिन का नाम देता है, नेस्टेड नेविगेशन को संभालता है, और वर्णन करता है कि API अनुपलब्ध होने पर UI क्या करता है। एक कमजोर उत्तर * लिखता है, एक अनुमति प्रॉम्प्ट की प्रतीक्षा करता है, और फीचर को सुरक्षित कहता है।
उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न
- मीटिंग और वीडियो फ्रेम किन सटीक ओरिजिन पर नेविगेट कर सकते हैं? एक अलग ओरिजिन पर नेविगेशन के लिए फ्रेम पॉलिसी में उस गंतव्य की आवश्यकता हो सकती है, या नेविगेशन के बाद फीचर को अस्वीकार किया जाना चाहिए।
- क्या मीटिंग फ्रेम नेस्टेड फ्रेम खोलता है? यदि हाँ, तो परिभाषित करें कि क्या डेलिगेशन जारी रह सकता है और यह मानने के बजाय कि पहले फ्रेम का ग्रांट हमेशा के लिए इनहेरिट हो गया है, नेस्टेड ओरिजिन का परीक्षण करें।
- कौन से ब्राउज़र और एम्बेडेड वेबव्यू समर्थित हैं? पॉलिसी सिंटैक्स सही हो सकता है जबकि एक पुराना रनटाइम एक अलग विफलता सतह को उजागर करता है।
- क्या कैमरा या माइक्रोफ़ोन कॉल अनिवार्य है? यदि यह वैकल्पिक है, तो पॉलिसी या उपयोगकर्ता की अनुमति अस्वीकार होने पर UI केवल-टेक्स्ट पथ प्रदान कर सकता है।
30-सेकंड का उत्तर ढांचा (Framework)
"मैं कैमरे और माइक्रोफ़ोन को डिफ़ॉल्ट रूप से () पर रखूँगा और रिस्पांस पॉलिसी में उन्हें केवल मीटिंग ओरिजिन को प्रदान करूँगा। मैं फुलस्क्रीन केवल वीडियो ओरिजिन को प्रदान करूँगा। प्रत्येक क्रॉस-ओरिजिन iframe अपने allow एट्रिब्यूट में इच्छित फीचर को दोहराएगा, क्योंकि हेडर और फ्रेम पॉलिसी दोनों की आवश्यकता होती है। फ्रेम उपयोगकर्ता अस्वीकृति से अलग पॉलिसी अस्वीकृति का पता लगाएगा, एक फ़ॉलबैक रेंडर करेगा, और अनुमति प्रॉम्प्ट को कभी भी ऑथराइजेशन के रूप में नहीं मानेगा। मैं रोलआउट से पहले सेम-ओरिजिन, क्रॉस-ओरिजिन, नेविगेशन, नेस्टेड-फ्रेम, मिसिंग-हेडर और ब्राउज़र-फ़ॉलबैक मामलों का परीक्षण करूँगा।"
चरण-दर-चरण गहन उत्तर
चरण 1: डिफ़ॉल्ट-अस्वीकार (deny-by-default) इन्वेंट्री के साथ शुरुआत करें
पेज और उसके स्वामित्व वाले ओरिजिन द्वारा उपयोग किए जाने वाले प्रत्येक पॉलिसी-नियंत्रित फीचर की सूची बनाएं। "मीटिंग" उत्पाद नाम से अनुमतियों का अनुमान न लगाएं। कैमरा और माइक्रोफ़ोन दो स्वतंत्र फीचर्स हैं। फुलस्क्रीन एक अन्य फीचर है। विज्ञापन स्पष्ट रूप से शून्य-पहुंच (zero-access) वर्ग हैं।
एक स्पष्ट हेडर का उपयोग करें जैसे:
Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example"), fullscreen=(self "https://video.example")सटीक ओरिजिन सूची किसी असंबंधित फ्रेम को ग्रांट प्राप्त करने से रोकती है। यदि डैशबोर्ड को स्वयं किसी फीचर तक नहीं पहुंचना चाहिए, तो self हटा दें और केवल आवश्यक फ्रेम ओरिजिन को ग्रांट दें, फिर सत्यापित करें कि पैरेंट पॉलिसी अभी भी डेलिगेशन की अनुमति देती है।
चरण 2: प्रत्येक iframe सीमा पर डेलिगेट करें
मीटिंग फ्रेम को केवल उसके दो फीचर्स मिलते हैं, और वीडियो फ्रेम को केवल फुलस्क्रीन मिलता है:
<iframe src="https://meet.example/room" allow="camera; microphone"></iframe>
<iframe src="https://video.example/player" allow="fullscreen"></iframe>
<iframe src="https://ad.example/slot" allow=""></iframe>क्रॉस-ओरिजिन फ्रेम के लिए, allow को छोड़ने से फीचर ब्लॉक हो जाता है, भले ही रिस्पांस हेडर ओरिजिन को सूचीबद्ध करता हो। इसके विपरीत, किसी विज्ञापन में allow="camera" जोड़ने से camera=() या हेडर में मौजूद नहीं होने वाले ओरिजिन को ओवरराइड नहीं किया जा सकता।
चरण 3: पॉलिसी और उपयोगकर्ता सहमति को अलग-अलग स्थितियों के रूप में मानें
Permissions-Policy यह तय करता है कि डॉक्यूमेंट किसी फीचर का उपयोग कर सकता है या नहीं। Permissions API और मीडिया प्रॉम्प्ट उपयोगकर्ता द्वारा दी गई अनुमति का प्रतिनिधित्व करते हैं। एक प्रॉम्प्ट दिखाई देने से पहले एक अवरुद्ध फीचर विफल हो सकता है। फ्रेम को "पॉलिसी अस्वीकृत", "उपयोगकर्ता अस्वीकृत", "असमर्थित", और "डिवाइस व्यस्त" को विभिन्न टेलीमेट्री और रिकवरी टेक्स्ट में मैप करना चाहिए।
क्लाइंट-साइड जांच को सुरक्षा सीमा न बनाएं। एम्बेडिंग पेज डेलिगेशन को नियंत्रित करता है, जबकि एप्लिकेशन अभी भी कॉल को प्रमाणित करता है और सर्वर पर रूम की सदस्यता को अधिकृत करता है।
चरण 4: नेविगेशन और नेस्टेड फ्रेम को स्पष्ट रूप से संभालें
यदि मीटिंग फ्रेम किसी सपोर्ट ओरिजिन पर नेविगेट कर सकता है, तो उस गंतव्य को allow पॉलिसी में केवल तभी शामिल करें जब वह विश्वसनीय हो और उसे समान फीचर की आवश्यकता हो। फ्रेम का प्रारंभिक src ओरिजिन और बाद का नेविगेशन ओरिजिन विनिमेय (interchangeable) नहीं हैं। नेस्टेड फ्रेम के लिए, प्रत्येक सीमा पर प्रभावी पॉलिसी को सत्यापित करें और स्वामित्व अस्पष्ट होने पर डिफ़ॉल्ट रूप से अस्वीकार करें।
चरण 5: अवलोकनीय (observable) परीक्षणों के साथ रोल आउट करें
जब प्लेटफ़ॉर्म इसकी अनुमति देता है, तो हेडर को रिपोर्ट-ओनली डायग्नोस्टिक्स या एक छोटे रूट कोहोर्ट में शिप करें, फिर पॉलिसी उल्लंघन, प्रॉम्प्ट परिणाम, कॉल पूर्णता और फ़ॉलबैक उपयोग की तुलना करें। सेम-ओरिजिन फ्रेम, अनुमत क्रॉस-ओरिजिन फ्रेम, गैर-सूचीबद्ध क्रॉस-ओरिजिन फ्रेम, मिसिंग allow एट्रिब्यूट, परिवर्तित सबडोमेन और फ्रेम नेविगेशन का परीक्षण करें। पुष्टि करें कि विज्ञापन कभी भी प्रॉम्प्ट तक नहीं पहुंचते हैं और अस्वीकृत मीटिंग फ्रेम टेक्स्ट चैट की पेशकश करता है।
उच्च-गुणवत्ता वाला नमूना उत्तर
"मैं थ्रेट मॉडल से पॉलिसी लिखूंगा। कैमरा और माइक्रोफ़ोन खाली अनुमतियों के रूप में शुरू होते हैं, फिर हेडर केवल meet.example को सूचीबद्ध करता है; फ़ुलस्क्रीन केवल video.example को सूचीबद्ध करता है। दो क्रॉस-ओरिजिन फ्रेम मैचिंग allow एट्रिब्यूट्स ले जाते हैं, जबकि विज्ञापन फ्रेम में कोई नहीं होता है। ब्राउज़र अभी भी उपयोगकर्ता की सहमति को नियंत्रित करता है, इसलिए मीटिंग कोड उपयोगकर्ता की अस्वीकृति से एक पॉलिसी ब्लॉक को अलग करता है और केवल-टेक्स्ट फ़ॉलबैक प्रदान करता है। मैं इस हेडर में ऑथराइजेशन नहीं रखूँगा: सर्वर अभी भी रूम और उपयोगकर्ता की जांच करता है।
इसे विश्व स्तर पर सक्षम करने से पहले, मैं मैट्रिक्स का अभ्यास करूँगा: अनुमत और गैर-सूचीबद्ध ओरिजिन, सेम-साइट लेकिन क्रॉस-ओरिजिन सबडोमेन, छूटा हुआ allow, फ्रेम नेविगेशन, नेस्टेड फ्रेम, असमर्थित ब्राउज़र, और एक अनुपलब्ध हेडर। टेलीमेट्री मीडिया को रिकॉर्ड किए बिना फीचर, फ्रेम ओरिजिन, पॉलिसी परिणाम, उपयोगकर्ता परिणाम और फ़ॉलबैक को रिकॉर्ड करती है। किसी विज्ञापन से कोई भी अप्रत्याशित प्रॉम्प्ट या किसी अविश्वसनीय ओरिजिन पर नेविगेशन के बाद कोई भी सफल एक्सेस रोलआउट को रोक देता है।"
सामान्य गलतियाँ
- कैमरा और माइक्रोफ़ोन के लिए
*का उपयोग करना → कोई भी योग्य फ्रेम एक शक्तिशाली फीचर का अनुरोध कर सकता है →()से शुरू करें और सटीक ओरिजिन जोड़ें। - केवल HTTP हेडर जोड़ना → एक क्रॉस-ओरिजिन iframe को अभी भी कंटेनर डेलिगेशन की आवश्यकता होती है → एक मैचिंग
allowएट्रिब्यूट सेट करें। - केवल
allowजोड़ना → फ्रेम पैरेंट पॉलिसी को चौड़ा नहीं कर सकता → रिस्पांस और प्रत्येक फ्रेम सीमा दोनों की जांच करें। - अनुपलब्ध प्रॉम्प्ट को ब्राउज़र बग मानना → उपयोगकर्ता की सहमति से पहले पॉलिसी अस्वीकृति हो सकती है → पॉलिसी, सहमति, समर्थन और डिवाइस स्थितियों की अलग-अलग रिपोर्ट करें।
- सबडोमेन को सेम-ओरिजिन मानना → सेम-साइट का अर्थ सेम-ओरिजिन नहीं है → प्रत्येक ओरिजिन को सूचीबद्ध करें और नेविगेशन का परीक्षण करें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: फीचर ब्लॉक क्यों है जबकि हेडर में मीटिंग ओरिजिन सूचीबद्ध है?
iframe के allow एट्रिब्यूट, सटीक स्कीम और पोर्ट की जाँच करें, और देखें कि क्या फ्रेम नेविगेट हुआ था। क्रॉस-ओरिजिन फ्रेम के लिए, हेडर अनुमति सूची और कंटेनर पॉलिसी का प्रतिच्छेदन (intersection) होता है; एक भी छूटा हुआ ग्रांट फीचर को ब्लॉक कर देता है।
अनुवर्ती 2: क्या आपको हेडर को छोड़ देना चाहिए और allow पर भरोसा करना चाहिए?
नहीं। एक स्पष्ट रिस्पांस पॉलिसी पेज के ओनर को एक शीर्ष-स्तरीय सीमा प्रदान करती है और नया फ्रेम जोड़े जाने पर आकस्मिक ग्रांट को रोकती है। इसे छोड़ने से कुछ फीचर्स के लिए अनुमति देने वाला डिफ़ॉल्ट रह सकता है, जिससे बाद का थर्ड-पार्टी एम्बेड पॉलिसी रिग्रेशन बन जाता है।
अनुवर्ती 3: मीटिंग फ्रेम एक सपोर्ट डोमेन पर नेविगेट करता है। क्या बदलता है?
गंतव्य का एक नए ओरिजिन के रूप में पुनर्मूल्यांकन करें। विश्वास, ऑथेंटिकेशन और डेटा हैंडलिंग की समीक्षा के बाद ही वहां कैमरा या माइक्रोफ़ोन की अनुमति दें; अन्यथा नेविगेशन को वे क्षमताएं खो देनी चाहिए और UI को फ़ॉलबैक की व्याख्या करनी चाहिए।
अनुवर्ती 4: क्या Permissions Policy सर्वर-साइड ऑथराइजेशन की जगह ले सकती है?
नहीं। यह किसी डॉक्यूमेंट में ब्राउज़र फीचर की उपलब्धता को नियंत्रित करती है। यह उपयोगकर्ता की पहचान, रूम की सदस्यता, या कोई अनुरोध कॉल में शामिल हो सकता है या नहीं, यह साबित नहीं करती है। उन जांचों को सर्वर पर रखें और पॉलिसी को ब्राउज़र की न्यूनतम-अधिकार (least-privilege) सीमा के रूप में मानें।