एम्बेडिंग और iframes

docs.scrimba.com

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

iframe एलिमेंट

एक iframe आपके अपने पेज के अंदर एक अन्य वेब पेज को रखता है। यह नाम "inline frame" का संक्षिप्त रूप है, और यह इसका एक अच्छा चित्र है: आपके पेज पर एक छोटी फ्रेम की गई खिड़की, जिसमें एक पूरी तरह से अलग पेज दिख रहा है। एक ब्लॉग पोस्ट पर एक YouTube वीडियो लगभग हमेशा एक iframe होता है।

आप इसे src विशेषता के साथ दिखाए जाने वाले पेज की ओर इशारा करते हैं, वही विशेषता जो एक छवि अपनी फ़ाइल के लिए उपयोग करती है:

<iframe src="https://www.youtube.com/embed/aqz-KE-bpKQ"></iframe>

वह एकल टैग YouTube प्लेयर को आपके पेज पर खींचता है। सोचें कि यह दीवार पर एक खिड़की लगाने जैसा है: दीवार आपका पेज है, और खिड़की के माध्यम से आप एक पूरी तरह से अलग कमरा देखते हैं।

एक <iframe> एक अलग, पूर्ण वेब पेज लोड करता है और इसे आपके पेज के अंदर एक आयत के रूप में प्रदर्शित करता है। src विशेषता उस पेज का पता रखती है, और फ्रेम के अंदर सब कुछ, इसका अपना HTML, CSS, और JavaScript, अपने आप पर चलता है, आपके पेज से अलग रहता है।

<iframe src="https://www.openstreetmap.org/export/embed.html"></iframe>

कोई भी चीज़ जो आप opening और closing टैग के बीच लिखते हैं वह fallback सामग्री है, केवल उन ब्राउज़र द्वारा दिखाई जाती है जो frames को सपोर्ट करने के लिए बहुत पुराने हैं, जो व्यावहारिक रूप से कोई नहीं हैं। फ्रेम पूरी तरह से इसकी विशेषताओं के माध्यम से कॉन्फ़िगर किया गया है, और अगला अनुभाग उन लोगों को कवर करता है जिन्हें आप वास्तव में सेट करेंगे।

एक <iframe> एक nested browsing context बनाता है: आपके दस्तावेज़ के अंदर एक पूर्ण, स्वतंत्र दस्तावेज़ (एक browsing context वह वातावरण है जिसमें एक एकल पेज चलता है, इसके अपने इतिहास, इसके अपने global scope, और DOM की अपनी कॉपी के साथ)। फ्रेम किसी अर्थवहन तरीके से आपके पेज के DOM ट्री का हिस्सा नहीं है; यह एक अलग पेज है जो आपके पेज पर एक बॉक्स के अंदर painted होता है।

वह अलगाव पूरा बिंदु है, और इसे same-origin policy द्वारा लागू किया जाता है: आपका पेज और framed पेज एक दूसरे को केवल तभी पढ़ या script कर सकते हैं जब वे एक origin साझा करते हैं (एक origin scheme, host, और port का संयोजन है, तो https://example.com और https://other.com अलग-अलग origins हैं)। एक same-origin फ्रेम जिसे आप iframe.contentWindow के माध्यम से JavaScript के साथ पहुंच सकते हैं; एक cross-origin फ्रेम एक sealed box है जिसे आप point कर सकते हैं लेकिन inspect नहीं कर सकते। लगभग हर embed जो आप place करते हैं, एक वीडियो, एक नक्शा, एक widget, cross-origin है, जो बिल्कुल यही है कि इसे सब कुछ सुरक्षित रखना है।

Junoiframe एलिमेंट एक <iframe> आपके पेज के अंदर एक पूरा अन्य वेब पेज दिखाता है, ठीक एक छोटी खिड़की की तरह जो एक अन्य कमरे में देख रही है। आप इसे src के साथ कहीं point करते हैं, ठीक उसी तरह जैसे एक छवि करती है। एक ब्लॉग पर वह YouTube प्लेयर? लगभग हमेशा इनमें से एक।

Junoiframe एलिमेंट एक <iframe> एक अलग, self-contained पेज लोड करता है और इसे आपके पेज पर एक बॉक्स में दिखाता है। इसका अपना HTML, CSS, और JavaScript आपके पेज से wall off रहता है। आप इसे पूरी तरह से विशेषताओं के माध्यम से src से शुरू करते हुए set करते हैं।

Junoiframe एलिमेंट एक फ्रेम एक nested browsing context है: एक पूरा अलग दस्तावेज़ अपने scope और DOM के साथ, आपका कोई branch नहीं। same-origin policy ही वह है जो इसे sealed रखता है, इसलिए एक cross-origin embed को आपके पेज द्वारा shown किया जा सकता है लेकिन scripted नहीं। वह wall feature है, limitation नहीं जिसे पार करना है।

वीडियो, नक्शे, और widgets को एम्बेड करना

अच्छी खबर: आप शायद ही कभी embed कोड को हाथ से लिखते हैं। जिस साइट से आप embed कर रहे हैं वह इसे आपके लिए लिखती है। YouTube पर आप Share क्लिक करते हैं, फिर Embed, और यह आपको paste करने के लिए एक तैयार-निर्मित <iframe> देता है। नक्शे, music players, और calendars सब एक ही तरह से काम करते हैं। आप उनके block को copy करते हैं और इसे अपने HTML में paste करते हैं।

<iframe src="https://www.youtube.com/embed/aqz-KE-bpKQ" width="560" height="315"></iframe>

width और height सेट करते हैं कि फ्रेम कितना बड़ा है, pixels में मापा जाता है। वे दो numbers बदलें और वीडियो आपके पेज पर बड़ा या छोटा हो जाता है।

अधिकांश embed कोड सीधे स्रोत से आता है। एक Share या Embed बटन देखें, और सेवा आपको एक <iframe> ब्लॉक देती है जो आपके लिए sized और pointed है। तीन विशेषताएं समझने लायक हैं बजाय केवल paste करने के:

<iframe
  src="https://www.youtube.com/embed/aqz-KE-bpKQ"
  width="560"
  height="315"
  title="Big Buck Bunny short film"
  loading="lazy"
></iframe>

width और height pixels में फ्रेम का आकार सेट करते हैं। title विशेषता screen readers के लिए फ्रेम को नाम देती है, जो इसे घोषित करते हैं ठीक उसी तरह जैसे वे किसी link के text को घोषित करते हैं, इसलिए एक title के बिना एक फ्रेम एक unlabelled "frame" के रूप में पढ़ा जाता है और किसी की मदद नहीं करता। loading="lazy" ब्राउज़र को framed page को download करने से रोकने के लिए कहता है जब तक reader इसके पास scroll न करे, जो embeds को पेज के नीचे initial load को slow करने से रोकता है।

एक फ्रेम के लिए जो अपने container को fit करने के लिए stretch करना चाहिए fixed pixel size की बजाय, width और height विशेषताओं को drop करें और इसे CSS के साथ size करें, aspect-ratio को use करते हुए एक वीडियो के proportions को सही रखने के लिए।

एक सेवा आपको जो embed snippet देती है वह एक reasonable default है, एक finished decision नहीं। कुछ विशेषताएं decide करती हैं कि यह production में कितनी अच्छी तरह behave करता है।

<iframe
  src="https://www.youtube-nocookie.com/embed/aqz-KE-bpKQ"
  title="Big Buck Bunny short film"
  loading="lazy"
  referrerpolicy="strict-origin-when-cross-origin"
  allowfullscreen
  style="width: 100%; aspect-ratio: 16 / 9; border: 0;"
></iframe>

title व्यावहारिक रूप से optional नहीं है: assistive technology (screen readers जैसे software जो पेज को aloud पढ़ता है) एक फ्रेम को एक landmark के रूप में treats करते हैं और इसका title घोषित करते हैं, तो एक missing one reading order में एक blank region छोड़ता है। loading="lazy" फ्रेम के document load को defer करता है जब तक यह viewport (पेज का visible area) के पास न आए, जो यहां बहुत मायने रखता है क्योंकि प्रत्येक फ्रेम एक full page load है, एक single asset नहीं। referrerpolicy नियंत्रण करता है कि आपके पेज का कितना URL Referer header में embedded service को भेजा जाता है (वह field जो ब्राउज़र attach करता है एक सर्वर को बताने के लिए कि एक request कहां से आया है), और इसे tighten करना आपके users के बारे में कम leak करता है। aspect-ratio के साथ responsively size करें बजाय fixed pixels के ताकि फ्रेम small screens पर reflow हो। रखने लायक एक habit: paste करने से पहले snippet को read करें, क्योंकि आप provider ने चुनी गई जो defaults inherit कर रहे हैं।

Junoवीडियो, नक्शे, और widgets को एम्बेड करना आप लगभग कभी embed कोड को अपने आप नहीं लिखते। YouTube, एक नक्शे, या एक player पर Share या Embed बटन खोजें, और यह आपको paste करने के लिए एक <iframe> देता है। इसे resize करने के लिए width और height बदलें। वह ज्यादातर job है।

Junoवीडियो, नक्शे, और widgets को एम्बेड करना स्रोत से embed कोड grab करें, फिर इसे tidy करें। screen readers को frame को नाम देने के लिए हमेशा एक title जोड़ें, और loading="lazy" ताकि पेज के नीचे एक फ्रेम first paint को slow न करे। flexible sizing के लिए, pixel width और height को drop करें और CSS aspect-ratio का use करें।

Junoवीडियो, नक्शे, और widgets को एम्बेड करना provider का snippet एक starting point है। reading order के लिए title, loading="lazy" क्योंकि एक फ्रेम एक whole page load है और एक asset नहीं, एक tight referrerpolicy ताकि आप अपने users के बारे में कम leak करें, और responsive sizing के लिए aspect-ratio। जो paste करते हैं वह read करें, क्योंकि आप हर default inherit करते हैं जो उन्होंने pick किया।

Sandboxing और permissions

क्योंकि एक फ्रेम एक पूरा अन्य पेज चलाता है, आप limit करना चाहते हैं कि उस पेज को क्या करने की अनुमति है। sandbox विशेषता ठीक वही करती है: यह फ्रेम को एक safety fence के पीछे रखती है।

<iframe src="widget.html" sandbox></iframe>

अपने आप पर sandbox के साथ, framed पेज सबसे strict setting में रखा जाता है: यह अपने scripts नहीं चला सकता, forms submit नहीं कर सकता, या नई windows pop open नहीं कर सकता। आप फिर एक-एक करके specific permissions को hand back करते हैं, केवल वे जो embed को actually need करते हैं। सोचें कि यह किसी को एक कमरा lend करने जैसा है लेकिन उन cabinets को lock करना जो आप opened नहीं चाहते।

दो विशेषताएं नियंत्रण करती हैं कि एक फ्रेम को क्या करने की अनुमति है। sandbox फ्रेम को restrict करता है, और allow device और browser features तक access grant करता है।

sandbox को no value के साथ जोड़ने से framed page जो कुछ भी कर सकता था वह लगभग सब कुछ block करता है: scripts, forms, popups, और अपने आप को same-origin के रूप में treat करना। आप इसे space-separated permission tokens को listing करके loosen करते हैं:

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-forms"
></iframe>

allow-scripts फ्रेम को JavaScript चलाने देता है, allow-forms इसे forms submit करने देता है, allow-popups इसे नई windows open करने देता है। केवल वह grant करें जो embed को need करता है। अलग allow विशेषता fullscreen, camera, और microphone जैसे sensitive browser features को govern करती है:

<iframe src="https://example.com/call" allow="camera; microphone; fullscreen"></iframe>

अगर एक feature allow में listed नहीं है, तो framed page इसे use नहीं कर सकता, भले ही इसका code ask करे।

दो distinct models यहां sit करते हैं, और इसे अलग रखना worth है। sandbox फ्रेम से capabilities को remove करता है; allow gated features तक access grant करता है। वे एक ही चीज़ के दो spellings नहीं हैं।

sandbox no value के साथ सभी restrictions को एक ही बार apply करता है: कोई scripts नहीं, कोई form submission नहीं, कोई popups नहीं, कोई auto-playing media नहीं, और, importantly, फ्रेम एक unique opaque origin में forced है (एक origin जो किसी अन्य से match नहीं करता, तो फ्रेम claim नहीं कर सकता कि वह किसी के साथ same-origin है, उस site को including जहां से वह load किया गया था)। आप capabilities को tokens के साथ back add करते हैं:

<iframe
  src="https://example.com/widget"
  sandbox="allow-scripts allow-popups allow-popups-to-escape-sandbox"
></iframe>

एक combination है जिससे बचना चाहिए। एक फ्रेम को both allow-scripts और allow-same-origin grant करना जो आपके अपने origin से load करता है framed page को code run करने देता है जो reach back कर सकता है और अपने आप को अपनी sandbox remove करने दे सकता है, जो पूरे point को defeat करता है। केवल उन दोनों को pair करें जब फ्रेम का content पूरी तरह trusted हो।

allow विशेषता एक Permissions Policy है (sensitive features जैसे camera, microphone, geolocation, या fullscreen को use करने के लिए कौन से pages may decide करने के लिए एक browser mechanism)। इसका default deny है: एक feature जो allow में named नहीं है फ्रेम के लिए unavailable है no matter क्या इसका script requests करता है। यही है कि आप एक video-call widget को place कैसे करते हैं जो camera को need करता है बिना भी page पर हर अन्य frame को वह camera दिए।

JunoSandboxing और permissions एक फ्रेम में sandbox जोड़ें और यह embedded page को lock down करता है: कोई scripts नहीं, कोई popups नहीं, कोई mischief नहीं। फिर आप केवल वह permissions hand back करते हैं जो इसे actually need करता है। यह एक कमरा lend करने जैसा है लेकिन कुछ cabinets को locked रखना।

JunoSandboxing और permissionssandbox फ्रेम को restrict करता है और आप इसे token by token loosen करते हैं, allow-scripts और allow-forms जैसे। अलग allow विशेषता वह है जो camera, microphone, या fullscreen grant करता है। प्रत्येक को केवल वह दें जो embed actually ask करता है।

JunoSandboxing और permissions दोनों models को straight रखें: sandbox capabilities को ले जाता है, allow gated features को grant करता है और deny को default करता है। trap दोनों को pair करना है allow-scripts के साथ allow-same-origin एक same-origin फ्रेम पर, क्योंकि यह page को अपने स्वयं की sandbox को unlock करने देता है। केवल वह करें जब आप पूरी तरह trust करते हैं कि अंदर क्या है।

सुरक्षा और performance cautions

Embeds handy हैं, लेकिन प्रत्येक frame एक पूरा अतिरिक्त page load करता है, तो उनका एक stack आपके को slow महसूस कर सकता है। दो habits आपको trouble से बाहर रखते हैं: केवल उन sites से embed करें जिन पर आप trust करते हैं, क्योंकि आप उनके page को अपने पर invite कर रहे हैं, और अधिक frames न जोड़ें जितना आपको need है।

पहले से loading="lazy" विशेषता यहां भी मदद करती है, जब तक reader उन तक scroll न करे तब तक frames को रोकते हुए। एक embed के लिए पहुंचें जब यह real work को save करता है, जैसे एक वीडियो या एक नक्शा, और इसे skip करें जब एक plain link same job को कर सकता है।

हर frame जो आप add करते हैं एक full page load है: इसका अपना HTML, अपना CSS, और अक्सर इसका अपना pile of JavaScript, सभी दूसरे server से fetched। तीन third-party embeds के साथ एक page really चार pages एक साथ loading है, जो यही है कि embed-heavy pages feel क्यों heavy हैं। offscreen frames पर loading="lazy" सबसे cheap win है, और तीन embeds पर एक prefer करना अगला है।

दूसरी concern भी है speed के beyond। आप अपने पेज को किसी और के frame के अंदर placed होने से protect कर सकते हैं, जो एक trick को stop करता है जहां एक attacker आपकी site को frame करता है और users को ऐसी चीज़ों पर click करने में trick करता है जो वह see नहीं कर सकते। वह protection server पर set किया जाता है, और advanced level दोनों headers को cover करता है जो यह करते हैं।

दो costs clear-eyed look के deserving हैं: एक frame आपके performance के लिए क्या करता है, और framing आपकी security के लिए क्या कर सकता है।

Performance पर, एक third-party frame एक single request नहीं है; यह एक nested document load है जो provider के full stack को run करता है (उनके markup, styles, fonts, analytics, और scripts) आपके page के अंदर। यह same network और main thread के लिए compete करता है, और इसके scripts अपने context में run करते हैं लेकिन same device पर, तो एक heavy embed आपके content को interactive बनने से delay कर सकता है। loading="lazy" offscreen frames को defer करता है, और embeds को consolidate करना किसी भी single एक को tune करने को beat करता है। एक embed को assume करने से पहले real cost को measure करें कि वह free है।

Security पर, risk clickjacking है: एक attacker आपके page को अपनी site पर एक frame में load करता है, इसे invisible बनाता है या overlay करता है, और एक signed-in user को आपके page पर एक real control पर click करने को lure करता है बिना realize किए। defence को declare करना है कि कौन, if anyone, आपके pages को frame कर सकता है, और यह HTML में नहीं बल्कि आपके server पर response header के साथ set किया जाता है:

• X-Frame-Options: DENY आपके page को किसी भी frame में load होने देने से refuse करता है। SAMEORIGIN केवल आपकी अपनी site को इसे frame करने देता है। यह older, coarser control है।
• Content-Security-Policy: frame-ancestors 'self' modern replacement है। frame-ancestors exactly list करता है कि कौन से origins आपके page को frame कर सकते हैं (एक Content-Security-Policy, या CSP, एक header है जो browser को बताता है कि content और behaviour के कौन से sources को permit करना है)। यह X-Frame-Options को supersede करता है, एक specific allowlist की अनुमति देता है एक blanket rule की बजाय, और यह है कि कोई भी चीज़ जिसके पास एक login या एक form है पर set करने के लिए।

Direction को note करें: sandbox और allow control करते हैं pages जिन्हें आप embed करते हैं, जबकि frame-ancestors और X-Frame-Options control करते हैं कि कौन आपको embed कर सकता है। दोनों directions matter करते हैं, और वे विभिन्न places में configure किए जाते हैं।

Junoसुरक्षा और performance cautions हर frame एक पूरा अतिरिक्त page load करता है, तो उनके एक pile आपके को slow down करते हैं। केवल उन sites से embed करें जिन पर आप trust करते हैं, count को low रखें, और loading="lazy" पर lean करें। अगर एक plain link same job को कर सकता है, तो link का use करें।

Junoसुरक्षा और performance cautions तीन embeds means चार pages एक ही बार loading, तो प्रत्येक frame को एक real cost के रूप में treat करें। offscreen frames पर loading="lazy" cheap win है, और fewer embeds एक को tune करना beat करता है। एक framing risk भी है protect करने के लिए worth है, जो deep dive में दो server headers के साथ cover करता है।

Junoसुरक्षा और performance cautions एक third-party frame provider के entire stack को run करता है आपके page के अंदर और आपके network और main thread के लिए compete करता है, तो assume करने से पहले measure करें कि यह cheap है। Security पर, clickjacking को stop करें declare करके कि कौन आपको frame कर सकता है: एक CSP में frame-ancestors modern control है, X-Frame-Options older एक। Direction को remember करें, क्योंकि sandbox guards pages जिन्हें आप embed करते हैं और frame-ancestors guards कौन आपको embed करता है।