Vai al contenuto

Widget B2B — histórico noutros dispositivos

Esta secção cobre o restauro do histórico pessoal do widget quando a mesma pessoa abre o site a partir de outro browser ou dispositivo.

O site tem de autenticar a pessoa. O backend obtém e guarda em privado a credencial de restauro para esse utilizador e esse widget. O browser passa-a a init() juntamente com o perfil.

Para o script apenas, ou para pré-preencher perfil e empresa ficando em sessão de convidado, vê Widget B2C. Endpoints, persistência e concorrência de restore_id: Integração técnica.

O que acrescenta em relação à sessão de convidado

Convidado Restauro
Login no site Não exigido Exigido, porque a credencial sai do teu backend
Dados que identificam o chat Credencial de convidado do browser, ou perfil passado a init() external_user_id e restore_id em conjunto
Continuidade Mesmo browser Browsers e dispositivos diferentes, no canal widget autorizado
Quem emite a credencial Loader Backend do site, através da Quoting24

name, phone, email, external_id, company_name e external_user_id, por si sós, não restauram o histórico. external_user_id sem restore_id não chega. O campo é restore_id, em snake case: restoreId não é um campo do loader.

O restauro não junta sessões de convidado antigas e não partilha o histórico entre colegas da mesma empresa. Diz respeito apenas ao canal widget.

Podes enviar os campos de empresa no mesmo init(). A associação ou a criação segue as regras do payload de convidado: é independente do restauro e não prova a identidade.

Fluxo

  1. O cliente inicia sessão no portal
  2. O backend autenticado pede à Quoting24 uma credencial (provisionRestoreId) ou reutiliza a já guardada
  3. A página chama init() com o mesmo external_user_id, o restore_id e, se forem precisos, os dados da empresa
  4. A Quoting24 verifica a credencial e mostra as conversas do widget visíveis para essa pessoa, incluindo as já fechadas
  5. No logout, ou na mudança de pessoa, a página chama reset() para o chat anterior não ficar no browser
widget.init({
  external_id: "52",
  company_name: "Ricambi Stella S.r.l.",
  name: "Mario Rossi",
  phone: "+393331234567",
  email: "mario.rossi@ricambi-stella.example",
  external_user_id: "1042",
  restore_id: session.restore_id,
});

restore_id é a resposta do backend para o utilizador autenticado. Usa-a sem a modificar. Máximo de 200 caracteres. Exige o external_user_id correspondente: ID estável da pessoa, não vazio, máximo de 100 caracteres após o trim. Não é um ID de empresa partilhado.

external_id compara-se com web_code. Juntamente com company_name pode criar a empresa em falta. Não autentica o utilizador e não substitui restore_id.

Pré-requisitos

Além do branding, dos domínios e do código de incorporação:

  • integração de backend autorizada na Quoting24
  • segredo privado da integração, só no servidor
  • endpoint de provisioning, normalmente widget.provisionRestoreId
  • arquivo privado na base do site, uma credencial por utilizador e widget

A chave pública no URL do script e o segredo de integração são valores diferentes. Vê a visão geral.

Endpoint no backend do site

/api/widget/session é um exemplo a implementar no portal. Não é um URL público da Quoting24.

POST /api/widget/session
Content-Type: application/json

{}

{
  "external_user_id": "1042",
  "external_id": "52",
  "company_name": "Ricambi Stella S.r.l.",
  "name": "Mario Rossi",
  "phone": "+393331234567",
  "email": "mario.rossi@ricambi-stella.example",
  "restore_id": "<credencial-devolvida-pela-quoting24>"
}
  • A identidade obtém-se da sessão do servidor, não de um ID escolhido pelo browser
  • Cache-Control: no-store
  • Não registes nem coloques em cache restore_id
  • Não ponhas segredos no URL do script nem em atributos data-*
  • Guarda a credencial antes de a devolver ao browser

O contrato para a Quoting24 (attempt_id, saved_restore_id, bloqueio, reutilização da chave) está na integração técnica.

Se o portal já tiver um endpoint autenticado que, para o utilizador atual, devolve o restore_id deste widget, usa essa resposta. Combina-a com o ID da pessoa e a referência da empresa na chamada a init().

Login, recarregamento, mudança de conta, logout

Distingue um recarregamento de página de uma mudança real de pessoa ou de conta.

  • Recarregamento com o mesmo login ainda ativo: init() sem reset(), para manter a sessão de convidado guardada se apenas voltas a passar o perfil. Com o restauro, reutiliza a credencial já persistida: não geres uma nova em cada visualização de página
  • Mudança de pessoa, mudança de conta, logout: reset() de imediato, depois o perfil novo, ou nenhum init() se o utilizador saiu
  • Descarta as respostas de restauro chegadas depois da mudança: uma resposta antiga não é um login novo
  • Numa SPA mantém uma única instância no layout principal. Uma mudança de rota não volta a lançar o provisioning

Se o restauro não estiver disponível podes oferecer o chat de convidado: reset(), depois init() sem restore_id. Esse chat fica separado do histórico restaurado.

Uma credencial inválida, de outro utilizador ou revogada é rejeitada. A Quoting24 não a converte em sessão de convidado. O botão «Riprova» do widget não pede por si só um restore_id novo ao teu backend. A interface atual está em italiano, por isso essa etiqueta está em italiano.

Exemplo de applyWidgetAuth e desmontagem: Integração técnica.

reset() esquece a sessão de convidado desta instância e a credencial guardada no browser. Não revoga restore_id no servidor e não fecha as sessões noutros dispositivos. O site tem de atualizar os outros separadores abertos.

Conversas anteriores

No histórico restaurado os chats já fechados podem aparecer como conversa anterior.

  • Abri-los para consulta não reabre a conversa antiga
  • As mensagens novas ficam na conversa ativa

Lista de verificação antes da entrada em produção

  • [ ] Segredo de integração só no servidor
  • [ ] external_user_id estável e por pessoa, idêntico entre o provisioning e init()
  • [ ] restore_id persistido antes da resposta ao browser, e reutilizado nas visitas seguintes
  • [ ] O mesmo utilizador num segundo browser: o mesmo histórico
  • [ ] Dois utilizadores da mesma empresa: históricos distintos
  • [ ] external_id e company_name verificados no ficheiro, sem esperar que restaurem o chat
  • [ ] Logout ou mudança de conta durante o fetch: nenhum chat do utilizador anterior no ecrã
  • [ ] Passagem convidado ↔ restauro com reset() pelo meio
  • [ ] Credencial revogada ou inválida: erro, sem recurso silencioso a convidado

Testes e sintomas: Verificar a integração · Resolução de problemas.