Vai al contenuto

Widget B2B — cronologia su altri dispositivi

Questa sezione copre il recupero della cronologia personale del widget quando la stessa persona apre il sito da un altro browser o dispositivo.

Il sito deve autenticare la persona. Il suo backend ottiene e conserva in privato la credenziale di ripristino per quell’utente e quel widget. Il browser la passa a init() insieme al profilo.

Per il solo script, o per precompilare profilo e azienda restando in sessione ospite, vedi Widget B2C. Endpoint, persistenza e concorrenza del restore_id: Integrazione tecnica.


Cosa aggiunge rispetto alla sessione ospite

Ospite Ripristino
Login sul sito Non richiesto Richiesto, perché la credenziale esce dal tuo backend
Dati che identificano la chat Credenziale ospite del browser, oppure profilo passato a init() external_user_id e restore_id insieme
Continuità Stesso browser Browser e dispositivi diversi, sul canale widget autorizzato
Chi emette la credenziale Loader Backend del sito, tramite Quoting24

name, phone, email, external_id, company_name e external_user_id, da soli, non ripristinano la cronologia. external_user_id senza restore_id non basta. Il campo è restore_id, in snake case: restoreId non è un campo del loader.

Il recupero non unisce vecchie sessioni ospite e non condivide la cronologia tra colleghi della stessa azienda. Riguarda solo il canale widget.

Puoi inviare nello stesso init() anche i campi azienda. L’associazione o la creazione dell’azienda segue le regole del payload ospite: è indipendente dal ripristino e non dimostra l’identità.


Flusso

  1. Il cliente effettua il login sul portale
  2. Il backend autenticato chiede a Quoting24 una credenziale (provisionRestoreId) oppure riutilizza quella già salvata
  3. La pagina chiama init() con lo stesso external_user_id, il restore_id e, se servono, i dati azienda
  4. Quoting24 verifica la credenziale e mostra le conversazioni del widget visibili per quella persona, comprese quelle già chiuse
  5. Al logout, o al cambio persona, la pagina chiama reset() così la chat precedente non resta sul 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 è la risposta del backend per l’utente autenticato. Usala senza modificarla. Massimo 200 caratteri. Richiede il corrispondente external_user_id: ID stabile della singola persona, non vuoto, massimo 100 caratteri dopo il trim. Non è un ID azienda condiviso.

external_id confronta web_code. Insieme a company_name può creare l’azienda mancante. Non autentica l’utente e non sostituisce restore_id.


Prerequisiti

Oltre a branding, domini e codice embed:

  • integrazione backend autorizzata in Quoting24
  • segreto privato dell’integrazione, solo sul server
  • endpoint di provisioning, di solito widget.provisionRestoreId
  • archivio privato nel database del sito, una credenziale per utente e widget

La chiave pubblica nell’URL dello script e il segreto di integrazione sono valori diversi. Vedi Panoramica.


Endpoint sul backend del sito

/api/widget/session è un esempio da implementare nel portale. Non è un URL pubblico di 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": "<credenziale-restituita-da-quoting24>"
}
  • L’identità si ricava dalla sessione server, non da un ID scelto dal browser
  • Cache-Control: no-store
  • Non loggare e non mettere in cache restore_id
  • Non mettere segreti nell’URL dello script o in attributi data-*
  • Salva la credenziale prima di restituirla al browser

Il contratto verso Quoting24 (attempt_id, saved_restore_id, lock, riutilizzo della chiave) è in Integrazione tecnica.

Se il portale ha già un endpoint autenticato che, per l’utente corrente, restituisce il restore_id di questo widget, usa quella risposta. Combinala con l’ID della persona e con il riferimento azienda nella chiamata a init().


Login, ricarica, cambio account, logout

Distingui un ricaricamento della pagina da un cambio reale di persona o account.

  • Ricaricamento con lo stesso login ancora attivo: init() senza reset(), così resta la sessione ospite salvata se stai solo ridando il profilo. Con il ripristino, riusa la credenziale già persistita: non generarne una nuova a ogni page view
  • Cambio persona, cambio account, logout: reset() subito, poi il nuovo profilo oppure nessun init() se l’utente è uscito
  • Scarta le risposte di ripristino arrivate dopo il cambio: una risposta vecchia non va trattata come un nuovo login
  • In una SPA tieni una sola istanza nel layout principale. Un cambio di route non rilancia il provisioning

Se il ripristino non è disponibile puoi offrire la chat ospite: reset(), poi init() senza restore_id. Quella chat resta separata dalla cronologia ripristinata.

Una credenziale non valida, di un altro utente o revocata viene rifiutata. Quoting24 non la converte in sessione ospite. Il pulsante «Riprova» del widget non chiede da solo un nuovo restore_id al backend.

Esempio di applyWidgetAuth e smontaggio: Integrazione tecnica.

Il reset() dimentica la sessione ospite di questa istanza e la credenziale salvata nel browser. Non revoca restore_id sul server e non chiude le sessioni sugli altri dispositivi. Le altre schede aperte vanno aggiornate dal sito.


Conversazioni precedenti

Nella cronologia ripristinata le chat già chiuse possono comparire come conversazione precedente.

  • Aprirle in consultazione non riapre la vecchia conversazione
  • I messaggi nuovi restano sulla conversazione attiva

Checklist prima del rilascio

  • [ ] Segreto di integrazione solo sul server
  • [ ] external_user_id stabile e per persona, identico tra provisioning e init()
  • [ ] restore_id persistito prima della risposta al browser, e riutilizzato alle visite successive
  • [ ] Stesso utente su un secondo browser: stessa cronologia
  • [ ] Due utenti della stessa azienda: cronologie distinte
  • [ ] external_id e company_name verificati in anagrafica, senza aspettarsi che ripristinino la chat
  • [ ] Logout o cambio account durante il fetch: nessuna chat del vecchio utente a schermo
  • [ ] Passaggio ospite ↔ ripristino con reset() in mezzo
  • [ ] Credenziale revocata o non valida: errore, senza fallback silenzioso a ospite

Test e sintomi: Verificare l’integrazione · Risoluzione dei problemi.