@bravophone/webphone 0.3.0 → 0.4.1

package/README.md

@@ -10,12 +10,17 @@ navegador.
 // Duas etapas de propósito: a consulta tem 5 min de cache, o bundle é
 // immutable. Assim as correções chegam em minutos, sem revalidar 30 kB a cada
 // visita — e sem os 7 dias de cache que a URL sem versão carrega.
-fetch('https://data.jsdelivr.com/v1/packages/npm/@bravophone/webphone/resolved')
+// cache:'no-store' na CONSULTA (~1 kB): sem ele, a resposta fica até 5 min
+// no navegador e uma publicação recém-saída não aparece — foi o que exigiu
+// Ctrl+Shift+R nos testes. O bundle continua vindo de cache immutable, então
+// o custo é uma requisição pequena por carregamento, não 30 kB.
+fetch('https://data.jsdelivr.com/v1/packages/npm/@bravophone/webphone/resolved',
+      { cache: 'no-store' })
   .then((r) => r.json())
   .then(({ version }) => {
     const s = document.createElement('script')
     s.src = `https://cdn.jsdelivr.net/npm/@bravophone/webphone@${version}/dist/bravophone.umd.js`
-    s.onload = () => Bravophone.init({ token: TOKEN_DO_USUARIO })
+    s.onload = () => Bravophone.init({ session: SESSAO_DO_LOGIN })
     s.onerror = () => console.error('Bravophone: falha ao carregar do CDN')
     document.head.appendChild(s)
   })
@@ -100,7 +105,7 @@ Testei mentalmente as duas rotas; o iframe ganha em quatro frentes de uma vez:
 1. **CSS.** O bundle traz Tailwind + `dark-theme.css` globais. Injetado na página do
    cliente, ele quebraria o site do cliente — e o CSS do cliente quebraria o webphone.
 2. **CORS, e este é o argumento decisivo.** Dentro do iframe, todo request para
-   `api.bravophone.com`, `reports.teambravotech.com` e `devices.wavoip.com` sai com
+   `pabx.teambravotech.com` e `devices.wavoip.com` sai com
    `Origin: https://webphone.bravophone.com` — **uma origem só, fixa**. Sem iframe,
    cada cliente novo exigiria liberar mais uma origem no CORS de três backends. Com
    iframe, a lista de origens do backend nunca cresce.
@@ -331,7 +336,7 @@ sync, ou versione por query string); `index.html` sempre com `no-cache`.
 
 ### 2. Backends — CORS
 
-Liberar **uma única origem** em `api.bravophone.com`, `reports.teambravotech.com` e
+Liberar **uma única origem** em `api.bravophone.com`, `pabx.teambravotech.com` e
 `devices.wavoip.com`:
 
 ```
@@ -390,9 +395,62 @@ document.head.appendChild(s)
 Cole isso **inline** na página, não como arquivo externo — um arquivo externo
 teria o mesmo problema de cache que estamos evitando.
 
+### Se uma publicação não aparecer
+
+Três caches diferentes, do mais provável ao menos:
+
+| O que está velho | Como saber | Solução |
+|---|---|---|
+| **A consulta de versão** | `Bravophone.version` mostra a anterior | Já resolvido: o snippet usa `cache: 'no-store'` |
+| **A página do integrador** | o próprio snippet mudou e não teve efeito | Não sirva o HTML com `max-age` longo |
+| **O bundle** | — | Não acontece: a URL é versionada e `immutable` |
+
+Durante o desenvolvimento, `Ctrl+Shift+R` limpa os três de uma vez — foi o que
+funcionou nos primeiros testes. Em produção não há como pedir isso ao usuário,
+e é por isso que o `no-store` está na consulta: sem ele, quem carregou a página
+nos últimos cinco minutos continua na versão anterior.
+
+Se ainda assim algo ficar para trás, `npm run purge` limpa as bordas do CDN —
+mas lembre que ele não alcança o navegador de ninguém.
+
 Os assets do webphone acompanham automaticamente: o `public_path` é gravado com
 a versão do pacote, então carregar o SDK 0.2.1 carrega o host 0.2.1.
 
+## A sessão que o webphone espera
+
+`init()` recebe a resposta do `/api/voxfree/login` inteira:
+
+```js
+Bravophone.init({
+  session: {
+    vxToken:    '…',   // obrigatório
+    expiresIn:  3600,  // segundos
+    sip:        '…',   // sem isto o webphone não registra
+    ramal:      '…',   // idem
+    tenant:     '…',
+    clienteId:  '…',
+    ramaisUrl:  '…',
+
+    // A segunda metade: sem ela o app fica na tela de login, mesmo com o
+    // vxToken válido. O checkToken do webphone exige as duas.
+    extension: { username: '…', password: '…', server: '…' },
+  },
+})
+```
+
+**Onde a credencial SIP fica.** O `extension` viaja apenas pela ponte
+(`postMessage`) e é aplicado no store em memória do webphone. Ele **não** entra
+no HTML do iframe nem no `localStorage` — a senha não fica legível no DOM da sua
+página. As outras sete chaves são pré-gravadas no storage, porque é de lá que o
+bundle as lê.
+
+O SDK grava essas chaves onde o bundle as procura, **antes** dele avaliar — a
+sessão já sobe autenticada, sem piscar a tela de login.
+
+`token: '…'` continua aceito como atalho para `{ vxToken }`, mas **sozinho não
+basta**: o webphone carrega, não registra, e o RouteSelector avisa "faça login
+pelo webphone" — justamente o que a auto-autenticação existe para evitar.
+
 ## Documentação
 
 | Documento | Para quem |
@@ -458,7 +516,7 @@ Bravophone.init({ token, mode: 'srcdoc' })     // na origem do próprio site
 | Você precisa manter | o domínio do host | nada |
 
 **Antes de oferecer o `srcdoc` a um cliente, a origem dele precisa estar na
-allowlist de CORS de `api.bravophone.com`, `reports.teambravotech.com` e
+allowlist de CORS de `api.bravophone.com`, `pabx.teambravotech.com` e
 `devices.wavoip.com`.** Sem isso o webphone carrega, aparece na tela e não
 registra — o navegador descarta as respostas. Isso é trabalho no **nosso**
 backend: o integrador não tem como liberar CORS de um servidor que não é dele.