Vai al contenuto

Widget B2B — historial en otros dispositivos

Esta sección cubre la recuperación del historial personal del widget cuando la misma persona abre el sitio desde otro navegador o dispositivo.

El sitio debe autenticar a la persona. Su backend obtiene y guarda en privado la credencial de restauración para ese usuario y ese widget. El navegador la pasa a init() junto con el perfil.

Para el script solo, o para precargar perfil y empresa quedándose en sesión de invitado, ve Widget B2C. Endpoints, persistencia y concurrencia de restore_id: Integración técnica.

Qué añade respecto a la sesión de invitado

Invitado Restauración
Login en el sitio No requerido Requerido, porque la credencial sale de tu backend
Datos que identifican el chat Credencial de invitado del navegador, o perfil pasado a init() external_user_id y restore_id juntos
Continuidad Mismo navegador Navegadores y dispositivos distintos, en el canal widget autorizado
Quién emite la credencial Loader Backend del sitio, a través de Quoting24

name, phone, email, external_id, company_name y external_user_id, por sí solos, no restauran el historial. external_user_id sin restore_id no basta. El campo es restore_id, en snake case: restoreId no es un campo del loader.

La restauración no une sesiones de invitado antiguas y no comparte el historial entre compañeros de la misma empresa. Solo afecta al canal widget.

Puedes enviar los campos de empresa en el mismo init(). La asociación o la creación sigue las reglas del payload de invitado: es independiente de la restauración y no demuestra la identidad.

Flujo

  1. El cliente inicia sesión en el portal
  2. El backend autenticado pide a Quoting24 una credencial (provisionRestoreId) o reutiliza la ya guardada
  3. La página llama a init() con el mismo external_user_id, el restore_id y, si hacen falta, los datos de empresa
  4. Quoting24 comprueba la credencial y muestra las conversaciones del widget visibles para esa persona, incluidas las ya cerradas
  5. Al cerrar sesión, o al cambiar de persona, la página llama a reset() para que el chat anterior no quede en el navegador
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 es la respuesta del backend para el usuario autenticado. Úsala sin modificarla. Máximo 200 caracteres. Exige el external_user_id correspondiente: ID estable de la persona, no vacío, máximo 100 caracteres tras el trim. No es un ID de empresa compartido.

external_id se compara con web_code. Junto con company_name puede crear la empresa que falta. No autentica al usuario y no sustituye a restore_id.

Requisitos previos

Además del branding, los dominios y el código de inserción:

  • integración de backend autorizada en Quoting24
  • secreto privado de la integración, solo en el servidor
  • endpoint de provisioning, normalmente widget.provisionRestoreId
  • almacén privado en la base del sitio, una credencial por usuario y widget

La clave pública de la URL del script y el secreto de integración son valores distintos. Ve la visión general.

Endpoint en el backend del sitio

/api/widget/session es un ejemplo para implementar en el portal. No es una URL pública de 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-devuelta-por-quoting24>"
}
  • La identidad se obtiene de la sesión del servidor, no de un ID elegido por el navegador
  • Cache-Control: no-store
  • No registres ni guardes en caché restore_id
  • No pongas secretos en la URL del script ni en atributos data-*
  • Guarda la credencial antes de devolverla al navegador

El contrato hacia Quoting24 (attempt_id, saved_restore_id, bloqueo, reutilización de la clave) está en la integración técnica.

Si el portal ya tiene un endpoint autenticado que, para el usuario actual, devuelve el restore_id de este widget, usa esa respuesta. Combínala con el ID de la persona y la referencia de empresa en la llamada a init().

Login, recarga, cambio de cuenta, logout

Distingue una recarga de página de un cambio real de persona o de cuenta.

  • Recarga con el mismo login aún activo: init() sin reset(), para conservar la sesión de invitado guardada si solo vuelves a pasar el perfil. Con la restauración, reutiliza la credencial ya persistida: no generes una nueva en cada vista de página
  • Cambio de persona, cambio de cuenta, logout: reset() de inmediato, luego el perfil nuevo, o ningún init() si el usuario salió
  • Descarta las respuestas de restauración llegadas después del cambio: una respuesta antigua no es un login nuevo
  • En una SPA mantén una sola instancia en el layout principal. Un cambio de ruta no vuelve a lanzar el provisioning

Si la restauración no está disponible puedes ofrecer el chat de invitado: reset(), luego init() sin restore_id. Ese chat queda separado del historial restaurado.

Una credencial no válida, de otro usuario o revocada se rechaza. Quoting24 no la convierte en sesión de invitado. El botón «Riprova» del widget no pide por sí solo un restore_id nuevo a tu backend. La interfaz actual está en italiano, así que esa etiqueta está en italiano.

Ejemplo de applyWidgetAuth y desmontaje: Integración técnica.

reset() olvida la sesión de invitado de esta instancia y la credencial guardada en el navegador. No revoca restore_id en el servidor y no cierra las sesiones en otros dispositivos. El sitio debe actualizar las demás pestañas abiertas.

Conversaciones anteriores

En el historial restaurado los chats ya cerrados pueden aparecer como conversación anterior.

  • Abrirlos para consultarlos no reabre la conversación antigua
  • Los mensajes nuevos se quedan en la conversación activa

Lista de comprobación antes de la puesta en marcha

  • [ ] Secreto de integración solo en el servidor
  • [ ] external_user_id estable y por persona, idéntico entre el provisioning y init()
  • [ ] restore_id persistido antes de la respuesta al navegador, y reutilizado en visitas posteriores
  • [ ] Mismo usuario en un segundo navegador: mismo historial
  • [ ] Dos usuarios de la misma empresa: historiales distintos
  • [ ] external_id y company_name comprobados en el fichero, sin esperar que restauren el chat
  • [ ] Logout o cambio de cuenta durante el fetch: ningún chat del usuario anterior en pantalla
  • [ ] Paso invitado ↔ restauración con reset() en medio
  • [ ] Credencial revocada o no válida: error, sin respaldo silencioso a invitado

Pruebas y síntomas: Verificar la integración · Resolución de problemas.