---
# System prepended metadata

title: Apresentação POC - AEM (Iframe/WebComponent)

---

# Apresentação POC - AEM (Iframe/WebComponent)

### Slide 2
![](https://i.imgur.com/jtkEp9X.png)

* Possibilitar gerar conteúdo dinâmico através do AEM, onde já exista um gerenciador de conteúdo amigável;
* Por não haver necessidade de alteração de código,
* não queremos que isso gere uma CRQ;

### Slide 3
![](https://i.imgur.com/1llucUh.png)

* nossa squad abordou 2 conceitos: Iframe / WebComponents para fins de teste;

### Slide 4
![](https://i.imgur.com/QKIIJmw.png)

* Como seria montado um webcomponent

### Slide 5
![](https://i.imgur.com/6tT9mGQ.png)

* Resultado do WebComponent

### Slide 6 (Pontos relevantes)
![](https://i.imgur.com/cINBWWZ.png)

* Por conta do shadow dom, o mesmo não deixa conteúdo vazar ações desnecessárias para fora
  * isso é muito bom pq não conflita coisas com css ou js;
* Intuito de realmente criar mini componentes; (emoji selector, color picker, etc)
* Caso precise monitorar algo como "loading" do nosso lado, ou tramitar informações entre o componente, é possível;
  * inclusive a parte de taguemaneto pode funcionar muito bem aqui;
* nesse ponto é importante freezar que não gera scroll desnecessário;


### Slide 7 (Pontos de conflito)

![](https://i.imgur.com/vZ9WDb4.png)

* Não é possível apenas pegar um código html, e tentar fazer ele virar um componente
    * 3 formas de fazer
        * 
    * Até tinhamos uma maneira antigamente (absoleta em 2020) chamada Import html
    * Injeção de HTML, poderiamos ter problemas de segurança com XSS, Cross-site scripting;


* Apesar do ponto xss, necessitamos de um endpoint publico e sem restrição de cors (localhost/dev/pre/prod)
* ACL
* Can I use, 95% criação de tag customizada, sem suporte
* Cairia melhor ser usado em um unico sistema
    * Criar no proprio MVE para o MVE
* AEM não se encaixa no modelo 

### Slide 8
![](https://i.imgur.com/yYhLltm.png)

* Como seria montado um iframe

### Slide 9
![](https://i.imgur.com/lI1Aseo.png)

* Resultado do Iframe

### Slide 10 (Pontos relevantes)

![](https://i.imgur.com/G1Uf9Yo.png)

* O recomendado é utilizar o postMessage para ter uma comunicação com o parent(pai)
    * Temos o atributo onload pra realizar alguma ação de loading do nosso lado, mas isso só serve para a mesma origem, onload não funciona com dominios externos;
    * Ou caso precisemos tramitar informações entre as páginas, é possível através do postMessage; (gera implementação no AEM)
* no quesito de largura atende muito bem com width 100%,
    * Mas para altura não é possível identificar o tamanho da página interna, gerando um scroll vertical na página;
    * É possível tratar isso emitindo eventos de resize da página incorporada para a página pai; (gera implementação no AEM)​
* Bom, é um iframe, acho que a melhor forma de representar isso é dizer que parece uma webview kkk

### Slide 11 (Pontos de conflito)

![](https://i.imgur.com/oO5BwzD.png)

* Aqui as páginas do AEM teriam que funcionar sempre em forma de páginas públicas sem a necessidade de autenticação​
    * Problema de CORS, liberar local/mve/dev/pre/prod​
    * O conteúdo desse iframe pode abrir páginas infinitas dentro do próprio iframe; (<a href /\>)
    * Não temos o controle do que será exibido; 404;

* Funciona bem com target _blank, mas quando é chamado um link sem ele, o conteúdo é carregado dentro do próprio iframe,
    * _blank perde o intuito do SPA;
    * navegabilidade; 
    * recursividade;

* Não seria legal passar via URL PUBLICA as permissões de ACL ou fixo/Móvel para o AEM tratar;
    * Isso acabaria tornando a FAQ um conteúdo limitado, independente da permissão do usuário;

* Tagueamento: Por ser uma area publica e sem autenticação:
    * o AEM não teria os dados do usuário logado p/ fazer o tagueamento (iframe não partilha isso);
    * talvez seria a implementação de eventos no AEM p ser tratado no MVE;

* Para cada funcionalidade de cada iframe tem a necessidade de mapear e implementar dos 2 lados;

    * Exemplos:

        * Gerenciamento de altura do iframe para não gerar scroll;
        * Opção de loader inicial para carregar o iframe;
        * Até questão de links internos do iframe, pra não entrar em recursividade;

* Não conseguimos garantir a qualidade desse iframe;
    * Se vai apresentar algum conteúdo de terceiro;
    * Se vai estar online sempre;
    * Se a qualidade vai estar 100% em 24/7;

### Slide 12 (Pontos de conflito)

![](https://i.imgur.com/pVO1UrN.png)

* Limitado a ser consumido somente páginas inteiras;
    * Banners, notícias, imagens
* Look & Feel vem de encontro com nossos padrões dentro do MVE;
    * Foi criado storybook pra ter tudo padronizado;
    * Manter esse padrão dos dois lados é custoso e trabalhoso;
    * Isso trás complexidade na sustentação


### Slide 13 (Conclusão WebComponents)

![](https://i.imgur.com/LKqxaMY.png)


### Slide 14 (Conclusão Iframe)

![](https://i.imgur.com/cDfE3r6.png)

3 pontos com subtopicos:
    * Segurança, limitação na navegação, nível de customização​

* CSP - Necessário fazer configurações no iframe
    * funcionaria bacana se estivesse no mesmo domínio;
    * para que seja ignorada a segurança padrão feita pelos browsers;
    * abrindo brechas/regras de excessão para fazer o consumo de conteúdo;
    * Essa configuração evita ataques de Cross Site Scripting (XSS) e também de qualquer dominio fazer o embed desse iframe (falsificação de conteúdo);

* Não seria algo para ser utilizado em larga escala, conteúdos sem a necessidade de autenticação;


### Slide 15 (Conclusão Iframe)

![](https://i.imgur.com/3ESr2CI.png)

Ditado: Para quem só sabe usar martelo, todo problema é um prego. (Abraham Maslow)

Não sabemos usar só o iframe como martelo, a gente tem outras maneiras de resolver essa questão;

### Slide 16 (Sugestão)

![](https://i.imgur.com/glD0d4W.png)
