Do objeto ao iframe - outras tecnologias de incorporação

Esta tradução está incompleta. Ajude a traduzir este artigo em inglês

Até agora você já deve ter aprendido a incorporar coisas em suas páginas da web, incluindo imagens, vídeo e áudio. Neste ponto, gostaria de ter um pouco de um passo para o lado, olhando para alguns elementos que permitem incorporar uma ampla variedade de tipos de conteúdo em suas páginas: as <iframe>,  <embed><object>elementos. <iframe>s são para incorporar outras páginas da Web, e as outras duas permitem incorporar PDFs, SVG e até Flash - uma tecnologia que está saindo, mas que você ainda verá semi-regularmente.

Pré-requisitos: Conhecimento básico em informática, software básico instalado , conhecimento básico sobre o trabalho com arquivos , familiaridade com os fundamentos de HTML (conforme abordado em Introdução ao HTML ) e os artigos anteriores deste módulo.
Objetivo:
Para saber como itens incorporar em páginas da web que usam <object>,  <embed><iframe>, como filmes em Flash e outras páginas da web.

Uma breve história de incorporação

Há muito tempo, na Web, era popular o uso de quadros para criar sites - pequenas partes de um site armazenadas em páginas HTML individuais. Elas foram incorporadas em um documento mestre chamado conjunto de quadros, que permitiu especificar a área na tela que cada quadro preenchia, como dimensionar as colunas e linhas de uma tabela. Eles foram considerados o auge da frescura entre a metade e o final dos anos 90, e havia evidências de que ter uma página da Web dividida em partes menores como essa era melhor para as velocidades de download - especialmente perceptível pelas conexões de rede que eram tão lentas na época. No entanto, eles tinham muitos problemas, que superavam quaisquer positivos à medida que as velocidades da rede ficavam mais rápidas, para que você não as veja mais sendo usadas.

Um pouco mais tarde (final dos anos 90, início dos anos 2000), as tecnologias de plug-in tornaram-se muito populares, como Java Applets e Flash - isso permitiu que os desenvolvedores da Web incorporassem conteúdo rico em páginas da Web, como vídeos e animações, que não estavam disponíveis apenas no HTML. A incorporação dessas tecnologias foi alcançada através de elementos como <object>, e os menos utilizados <embed>, e eles eram muito úteis na época. Desde então, ficaram fora de moda devido a muitos problemas, incluindo acessibilidade, segurança, tamanho do arquivo e muito mais; hoje em dia, a maioria dos dispositivos móveis não suporta mais esses plug-ins, e o suporte para desktop está saindo.

Finalmente, o elemento <iframe> apareceu (juntamente com outras formas de incorporar conteúdo, como <canvas><video> etc.). Isso fornece uma maneira de incorporar um documento da Web inteiro dentro de outro, como se fosse um <img>ou outro elemento, e é usado regularmente hoje .

Com a lição de história fora do caminho, vamos seguir em frente e ver como usar algumas delas.

Aprendizado ativo: usos clássicos de incorporação

Neste artigo, vamos pular direto para uma seção de aprendizado ativo, para fornecer imediatamente uma idéia real de para que servem as tecnologias de incorporação. O mundo on-line está muito familiarizado com o Youtube , mas muitas pessoas não conhecem alguns dos recursos de compartilhamento disponíveis. Vejamos como o YouTube nos permite incorporar um vídeo em qualquer página que gostamos de usar <iframe>.

  1. Primeiro, vá ao Youtube e encontre o vídeo que você gosta.
  2. Abaixo do vídeo, você encontrará um botão Compartilhar - selecione para exibir as opções de compartilhamento.
  3. Selecione o botão Incorporar e você receberá um <iframe>código - copie isso.
  4. Insira-o na caixa de entrada abaixo e veja qual é o resultado na saída .

Para pontos de bônus, você também pode tentar incorporar um mapa do Google no exemplo:

  1. Vá para o Google Maps e encontre um mapa que você gosta.
  2. Clique no "Menu Hamburger" (três linhas horizontais) no canto superior esquerdo da interface do usuário.
  3. Selecione a opção Compartilhar ou incorporar mapa .
  4. Selecione a opção Incorporar mapa, que fornecerá algum <iframe>código - copie isso.
  5. Insira-o na caixa de entrada abaixo e veja qual é o resultado na saída .

Se você cometer um erro, sempre poderá redefini-lo usando o botão Redefinir . Se você realmente ficar atolado, pressione o botão Mostrar solução para ver uma resposta.

Iframes em detalhes

Então, isso foi fácil e divertido, certo? Os elementos <iframe> foram projetados para permitir que você incorpore outros documentos da Web ao documento atual. Isso é ótimo para incorporar conteúdo de terceiros em seu site sobre o qual você pode não ter controle direto e não querer implementar sua própria versão - como vídeo de fornecedores de vídeo on-line, sistemas de comentários como Disqus , mapas on-line fornecedores de mapas, banners publicitários etc. Os exemplos editáveis ​​ao vivo que você está usando neste curso são implementados usando <iframe>s.

Existem algumas sérias preocupações de segurança a serem consideradas com <iframe>s, como discutiremos abaixo, mas isso não significa que você não deve usá-las em seus sites - apenas requer algum conhecimento e pensamento cuidadoso. Vamos explorar o código um pouco mais detalhadamente. Digamos que você queira incluir o glossário MDN em uma de suas páginas da web - você pode tentar algo como isto:

<iframe src="https://developer.mozilla.org/en-US/docs/Glossary"
        width="100%" height="500" frameborder="0"
        allowfullscreen sandbox>
  <p> 
    <a href="https://developer.mozilla.org/en-US/docs/Glossary">
       Fallback link for browsers that don't support iframes
    </a>
  </p>
</iframe>

Este exemplo inclui os fundamentos básicos necessários para usar um <iframe>:

allowfullscreen
Se definido, ele <iframe>poderá ser colocado no modo de tela cheia usando a API de tela cheia (um pouco além do escopo deste artigo).
frameborder
Se definido como 1, isso indica ao navegador para desenhar uma borda entre esse quadro e outros quadros, que é o comportamento padrão. 0 remove a borda. Usar isso não é mais recomendado, pois o mesmo efeito pode ser melhor alcançado usando em seu CSS .border: none;
src
Este atributo, como <video><img>, contém um caminho apontando para o URL do documento a ser incorporado.
width e height
Esses atributos especificam a largura e a altura que você deseja que o iframe seja.
Conteúdo alternativo
Da mesma forma que outros elementos semelhantes <video>, você pode incluir conteúdo de fallback entre as <iframe></iframe>tags de abertura e fechamento que aparecerão se o navegador não suportar <iframe>Nesse caso, incluímos um link para a página. É improvável que você encontre qualquer navegador que não suporte <iframe>s atualmente.
sandbox
Esse atributo, que funciona em navegadores um pouco mais modernos que o restante dos <iframe>recursos (por exemplo, IE 10 e superior), requer configurações de segurança mais elevadas; falaremos mais sobre isso na próxima seção.

Nota: Para melhorar a velocidade, é uma boa ideia definir o srcatributo do iframe com JavaScript após o carregamento do conteúdo principal. Isso torna sua página utilizável mais cedo e diminui o tempo de carregamento da página oficial (uma importante métrica de SEO ).

Preocupações com segurança

Acima, mencionamos preocupações de segurança - vamos abordar isso com mais detalhes agora. Não esperamos que você entenda todo esse conteúdo perfeitamente da primeira vez; queremos apenas que você fique ciente dessa preocupação e forneça uma referência para retornar à medida que for mais experiente e começar a considerar o uso de <iframe>s em seus experimentos e trabalhos. Além disso, não há necessidade de ter medo e não usar <iframe>s - você só precisa ter cuidado. Leia...

Fabricantes de navegadores e desenvolvedores da Web descobriram da maneira mais difícil que iframes são um alvo comum (termo oficial: vetor de ataque ) para pessoas más na Web (geralmente chamadas de hackers ou, mais precisamente, crackers ) atacarem se estiverem tentando modificar maliciosamente seu página da web ou induzir as pessoas a fazer algo que não desejam, como revelar informações confidenciais como nomes de usuário e senhas. Por esse motivo, engenheiros de especificações e desenvolvedores de navegadores desenvolveram vários mecanismos de segurança para torná- <iframe>los mais seguros, e também existem práticas recomendadas a serem consideradas - abordaremos alguns deles abaixo.

Clickjacking é um tipo comum de ataque iframe, no qual hackers incorporam um iframe invisível ao documento (ou incorporam o documento ao próprio site malicioso) e o usam para capturar as interações dos usuários. Essa é uma maneira comum de enganar os usuários ou roubar dados confidenciais.

Um primeiro exemplo rápido - tente carregar o exemplo anterior que mostramos acima em seu navegador - você pode encontrá-lo ao vivo no Github ( consulte o código-fonte também.) Na verdade, você não verá nada exibido na página e se olhar para o console nas ferramentas de desenvolvedor do navegador , você verá uma mensagem informando o motivo. No Firefox, você será informado sobre o Load negado pelo X-Frame-Options: https://developer.mozilla.org/en-US/docs/Glossary não permite o enquadramento . Isso ocorre porque os desenvolvedores que criaram o MDN incluíram uma configuração no servidor que serve as páginas do site para impedir que elas sejam incorporadas dentro de <iframe>s (consulte Configurar diretivas CSP, abaixo.) Isso faz sentido - uma página MDN inteira não faz sentido para ser incorporada em outras páginas, a menos que você queira fazer algo como incorporá-las ao seu site e reivindicá-las como suas - ou tentar roubar dados via clickjacking , que são coisas muito ruins para se fazer. Além disso, se todos começassem a fazer isso, toda a largura de banda adicional começaria a custar muito dinheiro à Mozilla.

Incorporar somente quando necessário

Às vezes, faz sentido incorporar conteúdo de terceiros - como vídeos e mapas do youtube -, mas você pode economizar muitas dores de cabeça se incorporar apenas conteúdo de terceiros quando completamente necessário. Uma boa regra geral para a segurança da Web é "Você nunca pode ser muito cauteloso. Se você fez isso, verifique-o de qualquer maneira. Se alguém o fez, assuma que é perigoso até prova em contrário".

Além da segurança, você também deve estar ciente dos problemas de propriedade intelectual. A maioria dos conteúdos tem direitos autorais, offline e online, mesmo o conteúdo que você não pode esperar (por exemplo, a maioria das imagens no Wikimedia Commons ). Nunca exiba conteúdo em sua página da Web, a menos que você seja o proprietário ou os proprietários tenham lhe dado uma permissão inequívoca por escrito. As penalidades por violação de direitos autorais são severas. Novamente, você nunca pode ser muito cauteloso.

Se o conteúdo for licenciado, você deverá obedecer aos termos da licença. Por exemplo, o conteúdo no MDN é licenciado sob CC-BY-SA . Isso significa que você deve creditar-nos adequadamente quando citar nosso conteúdo, mesmo que faça alterações substanciais.

Use HTTPS

HTTPS is the encrypted version of HTTP. You should serve your websites using HTTPS whenever possible:

  1. HTTPS reduces the chance that remote content has been tampered with in transit,
  2. HTTPS prevents embedded content from accessing content in your parent document, and vice versa.

Using HTTPS requires a security certificate, which can be expensive (although Let's Encrypt makes things easier) — if you can't get one, you may serve your parent document with HTTP. However, because of the second benefit of HTTPS above, no matter what the cost, you must never embed third-party content with HTTP. (In the best case scenario, your user's Web browser will give them a scary warning.) All reputable companies that make content available for embedding via an <iframe> will make it available via HTTPS — look at the URLs inside the <iframe> src attribute when you are embedding content from Google Maps or Youtube, for example.

Note: Github pages allow content to be served via HTTPS by default, so is useful for hosting content. If you are using different hosting and are not sure, ask your hosting provider about it.

Always use the sandbox attribute

You want to give attackers as little power as you can to do bad things on your website, therefore you should give embedded content only the permissions needed for doing its job. Of course, this applies to your own content, too. A container for code where it can be used appropriately — or for testing — but can't cause any harm to the rest of the codebase (either accidental or malicious) is called a sandbox.

Unsandboxed content can do way too much (executing JavaScript, submitting forms, popup windows, etc.) By default, you should impose all available restrictions by using the sandbox attribute with no parameters, as shown in our previous example.

If absolutely required, you can add permissions back one by one (inside the sandbox="" attribute value) — see the sandbox reference entry for all the available options. One important note is that you should never add both allow-scripts and allow-same-origin to your sandbox attribute — in that case, the embedded content could bypass the same origin security policy that stops sites from executing scripts, and use JavaScript to turn off sandboxing altogether.

Note: Sandboxing provides no protection if attackers can fool people into visiting malicious content directly (outside an iframe). If there's any chance that certain content may be malicious (e.g., user-generated content), please serve it from a different domain to your main site.

Configure CSP directives

CSP stands for content security policy and provides a set of HTTP Headers (metadata sent along with your web pages when they are served from a web server) designed to improve the security of your HTML document. When it comes to securing <iframe>s, you can configure your server to send an appropriate X-Frame-Options  header. This can prevent other websites from embedding your content in their web pages (which would enable clickjacking and a host of other attacks), which is exactly what the MDN developers have done, as we saw earlier on.

Note: You can read Frederik Braun's post On the X-Frame-Options Security Header for more background information on this topic. Obviously, it's rather out of scope for a full explanation in this article.

The <embed> and <object> elements

The <embed> and <object> elements serve a different function to <iframe> — these elements are general purpose embedding tools for embedding multiple types of external content, which include plugin technologies like Java Applets and Flash, PDF (which can be shown in a browser with a PDF plugin), and even content like videos, SVG and images!

Note: A plugin, in this context, refers to software that provides access to content the browser cannot read natively.

However, you are unlikely to use these elements very much — Applets haven't been used for years, Flash is no longer very popular, due to a number of reasons (see The case against plugins, below), PDFs tend to be better linked to than embedded, and other content such as images and video have much better, easier elements to handle those. Plugins and these embedding methods are really a legacy technology, and we are mainly mentioning them in case you come across them in certain circumstances like intranets, or enterprise projects.

If you find yourself needing to embed plugin content, this is the kind of information you'll need, at a minimum:

<embed> <object>
URL of the embedded content src data
accurate media type of the embedded content type type
height and width (in CSS pixels) of the box controlled by the plugin height
width
height
width
names and values, to feed the plugin as parameters ad hoc attributes with those names and values single-tag <param> elements, contained within <object>
independent HTML content as fallback for an unavailable resource not supported (<noembed> is obsolete) contained within <object>, after <param> elements

Note: <object> requires a data attribute, a type attribute, or both. If you use both, you may also use the typemustmatch attribute (only implemented in Firefox, as of this writing). typemustmatch keeps the embedded file from running unless the type attribute provides the correct media type. typemustmatch can therefore confer significant security benefits when you're embedding content from a different origin (it can keep attackers from running arbitrary scripts through the plugin).

Here's an example that uses the <embed> element to embed a Flash movie (see this live on Github, and check the source code too):

<embed src="whoosh.swf" quality="medium"
       bgcolor="#ffffff" width="550" height="400"
       name="whoosh" align="middle" allowScriptAccess="sameDomain"
       allowFullScreen="false" type="application/x-shockwave-flash"
       pluginspage="http://www.macromedia.com/go/getflashplayer">

Pretty horrible, isn't it? The HTML generated by the Adobe Flash tool tended to be even worse, using an <object> element with an <embed> element embedded in it, to cover all bases (check out an example.) Flash was even used successfully as fallback content for HTML5 video, for a time, but this is increasingly being seen as not necessary.

Now let's look at an <object> example that embeds a PDF into a page (see the live example and the source code):

<object data="mypdf.pdf" type="application/pdf"
        width="800" height="1200" typemustmatch>
  <p>You don't have a PDF plugin, but you can 
    <a href="mypdf.pdf">download the PDF file.
    </a>
  </p>
</object>

PDFs were a necessary stepping stone between paper and digital, but they pose many accessibility challenges and can be hard to read on small screens. They do still tend to be popular in some circles, but it is much better to link to them so they can be downloaded or read on a separate page, rather than embedding them in a webpage.

The case against plugins

Once upon a time, plugins were indispensable on the Web. Remember the days when you had to install Adobe Flash Player just to watch a movie online? And then you constantly got annoying alerts about updating Flash Player and your Java Runtime Environment. Web technologies have since grown much more robust, and those days are over. For virtually all applications, it's time to stop delivering content that depends on plugins and start taking advantage of Web technologies instead.

  • Broaden your reach to everyone. Everyone has a browser, but plugins are increasingly rare, especially among mobile users. Since the Web is easily used without any plugins, people would rather just go to your competitors' websites than install a plugin.
  • Give yourself a break from the extra accessibility headaches that come with Flash and other plugins.
  • Stay clear of additional security hazards. Adobe Flash is notoriously insecure, even after countless patches. In 2015, Alex Stamos, then-Chief Security Officer at Facebook,  requested that Adobe discontinue Flash.

Note: Due to its inherent issues and the lack of support for Flash, Adobe announced that they would stop supporting it at the end of 2020.  As of January 2020, most browsers block Flash content by default, and by December 31st of 2020, all browsers will have completly removed all Flash functionality. Any existing Flash content will be inaccessable after that date.

So what should you do? If you need interactivity, HTML and JavaScript can readily get the job done for you with no need for Java applets or outdated ActiveX/BHO technology. Instead of relying on Adobe Flash, you should use HTML5 video for your media needs, SVG for vector graphics, and Canvas for complex images and animations. Peter Elst was already writing some years ago that Adobe Flash is rarely the right tool for the job. As for ActiveX, even Microsoft's Edge browser no longer supports it.

Test your skills!

You've reached the end of the this article, but can you remember the most important information? You can find some further tests to verify that you've retained this information before you move on — see Test your skills: Multimedia and embedding.

Summary

The topic of embedding other content in web documents can quickly become very complex, so in this article, we've tried to introduce it in a simple, familiar way that will immediately seem relevant, while still hinting at some of the more advanced features of the involved technologies. To start with, you are unlikely to use embedding for much beyond including third-party content like maps and videos on your pages. As you become more experienced, however, you are likely to start finding more uses for them.

There are many other technologies that involve embedding external content besides the ones we discussed here. We saw some in earlier articles, such as <video>, <audio>, and <img>, but there are others to discover, such as <canvas> for JavaScript-generated 2D and 3D graphics, and <svg> for embedding vector graphics. We'll look at SVG in the next article of the module.

In this module