Do objeto ao iframe - outras tecnologias de incorporação
Até agora você já deve ter aprendido a incorporar coisas em suas páginas da web, incluindo imagens, vídeo e áudio. Neste ponto, gostariamos de dar um passo para o lado, olhando para alguns elementos que permitem incorporar uma ampla variedade de tipos de conteúdo em suas páginas: os elementos <iframe>
, <embed>
e <object>
. <iframe>
s são para incorporar outras páginas da Web, e as outras duas permitem incorporar recursos externos como arquivos PDF.
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: |
Uma breve história de incorporação
Há muito tempo, na Web, era popular o uso de frames para criar sites - pequenas partes de um site armazenadas em páginas HTML individuais. Elas foram incorporadas em um documento mestre chamado frameset, que permitiu especificar a área na tela que cada frame 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 o menos utilizado <embed>
, 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, como o Flash.
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 gostariamos de usar um <iframe>
.
- Primeiro, vá ao Youtube e encontre o vídeo que você gosta.
- Abaixo do vídeo, você encontrará um botão Compartilhar - selecione para exibir as opções de compartilhamento.
- Selecione o botão Incorporar e você receberá algum código
<iframe>
- copie isso. - 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:
- Vá para o Google Maps e encontre um mapa que você gosta.
- Clique no "Menu Hamburger" (três linhas horizontais) no canto superior esquerdo da interface do usuário.
- Selecione a opção Compartilhar ou incorporar mapa.
- Selecione a opção Incorporar mapa, que fornecerá algum código
<iframe>
- copie isso. - 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 de fornecedores de mapas on-line, 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 com 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:
<head>
<style>
iframe {
border: none;
}
</style>
</head>
<body>
<iframe
src="https://developer.mozilla.org/pt-BR/docs/Glossary"
width="100%"
height="500"
allowfullscreen
sandbox>
<p>
<a href="/pt-BR/docs/Glossary">
Link alternativo para navegadores que não suportam iframes
</a>
</p>
</iframe>
</body>
Se você olhar para o console do seu navegador, verá uma mensagem de erro parecida com a seguinte:
Refused to display 'https://developer.mozilla.org/' in a frame because it set 'X-Frame-Options' to 'deny'.
A seção Preocupações com segurança abaixo entra em mais detalhes sobre o motivo pelo qual você vê esse erro, mas primeiro, vamos dar uma olhada no que nosso código está fazendo.
Este exemplo inclui os fundamentos básicos necessários para usar um <iframe>
:
border: none
-
Se usado, o
<iframe>
é mostrado sem um borda ao seu redor. Caso contrário, por padrão, navegadores mostram o<iframe>
com uma borda ao seu redor (o que é geralmente indesejável). allowfullscreen
-
Se definido, o
<iframe>
poderá ser colocado no modo de tela cheia usando a Fullscreen API (um pouco além do escopo deste artigo). src
-
Este atributo, como
<video>
/<img>
, contém um caminho apontando para o URL do documento a ser incorporado. width
eheight
-
Esses atributos especificam a largura e a altura que você deseja no iframe.
sandbox
-
Esse atributo, que funciona em navegadores um pouco mais modernos que o restante dos recursos
<iframe>
(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 atributo src
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: attack vector ) para pessoas más na Web (geralmente chamadas de hackers ou, mais precisamente, crackers ) atacarem se estiverem tentando modificar maliciosamente sua 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ár os <iframe>
mais seguros, e também existem práticas recomendadas a serem consideradas - abordaremos algumas delas abaixo.
Nota: 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 Carregamento negado pelo X-Frame-Options: "https://developer.mozilla.org/pt-BR/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é provar o 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 é a versão criptografada do HTTP. Você deve utilizar HTTPS em seus websites sempre que possível:
- HTTPS reduz a chance de que conteúdo remoto tenha sido adulterado no caminho.
- HTTPS previne que o conteúdo que tenha incorporado ao site acesse conteúdo em seu documento de origem, e vice-versa.
Utilizar HTTPS requer um certificado de segurança, que pode ser bem caro (apesar que o Let's Encrypt deixe as coisas mais fáceis) — se você não puder obter um certificado, você deve fornecer seus documentos com HTTP. Contudo, por conta do segundo benefício do HTTPS descrito acima, não importa o custo, você nunca deve incorporar conteúdo de terceiros em HTTP. (No caso do melhor cenário, o navegador de seu usuário irá mostra-lo um aviso assustador.) Todas as empresas com boa reputação irão fornecer conteúdo para ser incoporado por meio do <iframe>
disponível através de HTTPS — veja a URLs dentro do <iframe>
no atributo src
, quando você está incorporando conteúdo do Google Maps ou Youtube, por exemplo.
Nota: Páginas do Github permitem que conteúdo seja fornecido via HTTPS por padrão, então é útil para hospedar conteúdo. Se você está utilizando uma hospedagem diferente e não tem certeza do mesmo, pergunte sobre com o seu provedor de hospedagem.
Sempre utilize o atributo sandbox
Você deseja que os atacantes tenham a menor quantidade possível de poder para causar danos ao seu website, portanto, você deve dar ao conteúdo incorporado apenas a permissão para fazer o seu trabalho. É claro, isto se aplica ao seu próprio conteúdo, também. Um container para código onde ele possa ser utilizado apropriadamente — ou para testes — mas não pode causar nenhum dano ao resto do código base (tanto acidental quanto malicioso) é chamado sandbox.
Conteúdo fora de uma sandbox pode fazer muito mais que o esperado (executar JavaScript, submeter forms, criar novas janelas no navegador, etc.) Por padrão, você deve impor todas as restrições disponíveis utilizando o atributo sandbox
sem parâmetros, como mostrado em nosso exemplo anterior.
Se absolutamente necessário, você pode adicionar permissões uma a uma (dentro do valor do atributo sandbox=""
) — veja em sandbox
as referências de entrada para todas as opções disponíveis. Uma nota importante é que você nunca deve adicionar ambos allow-scripts
e allow-same-origin
no atributo sandbox — neste caso, conteúdo incorporado pode burlar a política de segurança de mesmo destino que impede sites de executarem scripts, e utilizar JavaScript para desativar o sandboxing completamente.
Nota: Sandboxing não fornece nenhuma proteção se atacantes puderem enganar os usuários para que visitem conteúdo malicioso diretamete (fora de um iframe
). Se existir qualquer chance que certo conteúdo possa ser malicioso (exemplo, conteúdo gerado por usuários), por favor forneça-o em um domain diferente de seu site principal.
Configure diretivas CSP
CSP significa política de segurança de conteúdo e fornece um conjunto de cabeçalhos HTTP (metadados enviados junto com suas páginas da web quando são veiculados de um servidor da web) projetados para melhorar a segurança do seu documento HTML. Quando se trata de proteger <iframe>
s, você pode configurar seu servidor para enviar um cabeçalho X-Frame-Options
apropriado. Isso pode impedir que outros sites incorporem seu conteúdo em suas páginas da Web (o que habilitaria o clickjacking e vários outros ataques), exatamente o que os desenvolvedores do MDN fizeram, como vimos anteriormente.
Nota: Você pode ler a publicação de Frederik Braun X-Frame-Options Security Header para obter mais informações sobre este tópico. Obviamente, está fora do escopo uma explicação completa neste artigo.
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!
Nota: 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 |
Nota: <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.
Nota: 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.