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

### Slide 2

* 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

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

### Slide 4

* Como seria montado um webcomponent

### Slide 5

* Resultado do WebComponent

### Slide 6 (Pontos relevantes)

* 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)


* 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

* Como seria montado um iframe

### Slide 9

* Resultado do Iframe

### Slide 10 (Pontos relevantes)


* 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)


* 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)


* 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)


### Slide 14 (Conclusão Iframe)


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)


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)