No Webapp o TWebEngine é um <Iframe/> e, por questões de segurança (Same-origin_policy), os navegadores bloqueiam scripts que tentam acessar ou interagir com um iframe que possua uma origem diferente da página principal.
Essa restrição é fundamental para evitar falhas de segurança, como por exemplo a técnica maliciosa de Clickjacking.
Quando a origem (protocolo, nome do host e porta) do conteúdo dentro do TWebEngine difere da origem do Webapp, o navegador impõe bloqueios que afetam dois mecanismos críticos:
Controle de Inatividade (InactiveTimeout): Os eventos que controlam o timeout são disparados pela navegação entre componentes AdvPL (Tab/Enter). Ao utilizar o TWebEngine, o Webapp só consegue capturar esses eventos se o protocolo, nome do host e a porta forem da mesma origem. Caso contrário, o sistema pode perder o controle de inatividade e a sessão cair.
Teclas de Atalho e Intercepção de Eventos: O navegador bloqueia a propagação de eventos de teclado entre domínios diferentes. Se o Webapp for acessado por uma porta direta e o componente (ex: PO-UI) por outra, o Webapp não conseguirá interceptar as teclas de atalho, fazendo com que elas parem de funcionar dentro do componente.
🚨 O mecanismo da Porta Multiprotocolo pode ajudar, garantindo que possam publicar sub-rotinas, respeitando o mesmo protocolo+host-name+porta, mudando apenas a rota para esta sub-rotina.
Exemplo:
Neste exemplo temos dois serviços (sub-rotinas) utilizando o mesmo caminho, cada um em sua respectiva rota, o primeiro o WebApp, o segundo o WebMonitor.
| Protocolo | Host name / IP | Porta | Rota |
|---|---|---|---|
| http:// | 10.173.1.12 | :8081 | /webapp |
| http:// | 10.173.1.12 | :8081 | /webmonitor |
A origem é considerada diferente se pelo menos uma das seguintes partes do endereço não for mantida: protocol://hostname:port/...
O protocolo, o nome do host e a porta devem ser os mesmos.
OBS: Se pelo menos uma das seguintes partes do endereço for diferente, o smartclient pode perder por controle de inatividade e navegação pelo (iframe/twebengine) pode cair.
Veja o que aconteceria ao tentar acessar as seguintes URLs de http://www.totvs.com/home/index.html
| URL | RESULTADO |
|---|---|
| http://www.totvs.com/home/other.html | SUCESSO |
| http://www.totvs.com/dir/inner/another.php | SUCESSO |
| http://www.totvs.com:80 | SUCESSO (porta default para HTTP) |
| http://www.totvs.com:2255 | FALHA: diferente porta |
| http://data.totvs.com/dir/other.html | FALHA: diferente hostname |
| https://www.totvs.com/home/index.html:80 | FALHA: diferente protocolo |
| ftp://www.totvs.com:21 | FALHA: diferente protocolo & porta |
| https://google.com/search?q=james+bond | FALHA: diferente protocolo, porta & hostname |
Para garantir o funcionamento correto, o Webapp e o conteúdo em PO-UI devem compartilhar a mesma origem. A recomendação é o uso da Porta Multiprotocolo.
Exemplo de configuração no AppServer:
[General]
app_environment=environment
inactiveTimeout=60
Partindo do principio que o protocolo, nome do host e a porta são iguais, logo não teriamos problemas com o Same-origin_policy e InactiveTimeout.
Exemplo da URL montada : http://hostname:1232/webapp/
TWebEngine
Servidor local
Dessa forma o Webapp tem o controle total de inatividade e a funcionalidade das teclas de atalho, pois o protocolo, nome do host e a porta satisfaz as três condições do (Same-origin_policy).