Widget B2B — Verlauf auf anderen Geräten

Dieser Abschnitt behandelt die Wiederherstellung des persönlichen Widget-Verlaufs, wenn dieselbe Person die Website von einem anderen Browser oder Gerät öffnet.

Die Website muss die Person authentifizieren. Ihr Backend holt den Wiederherstellungsnachweis für diesen Benutzer und dieses Widget und speichert ihn privat. Der Browser übergibt ihn zusammen mit dem Profil an init().

Für das Skript allein oder um Profil und Unternehmen vorauszufüllen und in der Gastsitzung zu bleiben, siehe Widget B2C. Endpunkte, Persistenz und Nebenläufigkeit von restore_id: Technische Integration.

Was gegenüber der Gastsitzung hinzukommt

	Gast	Wiederherstellung
Anmeldung auf der Website	Nicht erforderlich	Erforderlich, weil der Nachweis aus Ihrem Backend kommt
Daten, die den Chat identifizieren	Gastnachweis des Browsers oder an `init()` übergebenes Profil	`external_user_id` und `restore_id` zusammen
Kontinuität	Derselbe Browser	Andere Browser und Geräte, auf dem freigegebenen Widget-Kanal
Wer den Nachweis ausstellt	Loader	Backend der Website, über Quoting24

name, phone, email, external_id, company_name und external_user_id allein stellen den Verlauf nicht wieder her. external_user_id ohne restore_id reicht nicht. Das Feld heißt restore_id, in Snake Case: restoreId ist kein Feld des Loaders.

Die Wiederherstellung führt alte Gastsitzungen nicht zusammen und teilt den Verlauf nicht unter Kollegen desselben Unternehmens. Sie gilt nur für den Widget-Kanal.

Die Unternehmensfelder können im selben init() mitgesendet werden. Zuordnung oder Anlage folgt den Regeln des Gast-Payloads: sie ist unabhängig von der Wiederherstellung und beweist keine Identität.

Ablauf

Der Kunde meldet sich im Portal an
Das authentifizierte Backend fordert bei Quoting24 einen Nachweis an (provisionRestoreId) oder verwendet den schon gespeicherten erneut
Die Seite ruft init() mit derselben external_user_id, der restore_id und, falls nötig, den Unternehmensdaten auf
Quoting24 prüft den Nachweis und zeigt die für diese Person sichtbaren Widget-Unterhaltungen, einschließlich geschlossener
Beim Abmelden oder beim Personenwechsel ruft die Seite reset() auf, damit der vorherige Chat nicht im Browser bleibt

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 ist die Backend-Antwort für den authentifizierten Benutzer. Unverändert verwenden. Höchstens 200 Zeichen. Sie verlangt die passende external_user_id: stabile ID der einzelnen Person, nicht leer, höchstens 100 Zeichen nach dem Trim. Das ist keine gemeinsame Unternehmens-ID.

external_id wird mit web_code verglichen. Zusammen mit company_name kann sie das fehlende Unternehmen anlegen. Sie authentifiziert den Benutzer nicht und ersetzt restore_id nicht.

Voraussetzungen

Zusätzlich zu Branding, Domains und Einbettungscode:

eine in Quoting24 freigegebene Backend-Integration
das private Integrationsgeheimnis, nur auf dem Server
ein Provisioning-Endpunkt, gewöhnlich widget.provisionRestoreId
ein privater Speicher in der Datenbank der Website, ein Nachweis pro Benutzer und Widget

Der öffentliche Schlüssel in der Skript-URL und das Integrationsgeheimnis sind verschiedene Werte. Siehe Übersicht.

Endpunkt im Backend der Website

/api/widget/session ist ein Beispiel, das im Portal zu implementieren ist. Es ist keine öffentliche Quoting24-URL.

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": "<von-quoting24-zurueckgegebener-nachweis>"
}

Die Identität kommt aus der Serversitzung, nicht aus einer vom Browser gewählten ID
Cache-Control: no-store
restore_id nicht protokollieren und nicht cachen
Keine Geheimnisse in die Skript-URL oder in öffentliche data-*-Attribute setzen
Den Nachweis vor der Antwort an den Browser speichern

Der Vertrag gegenüber Quoting24 (attempt_id, saved_restore_id, Sperre, Wiederverwendung des Schlüssels) steht in der technischen Integration.

Hat das Portal schon einen authentifizierten Endpunkt, der für den aktuellen Benutzer die restore_id dieses Widgets zurückgibt, diese Antwort verwenden. Sie mit der Personen-ID und der Unternehmensreferenz im Aufruf von init() verbinden.

Anmeldung, Neuladen, Kontowechsel, Abmeldung

Ein Neuladen der Seite von einem echten Personen- oder Kontowechsel unterscheiden.

Neuladen bei noch aktiver Anmeldung: init() ohne reset(), damit die gespeicherte Gastsitzung bleibt, wenn nur das Profil erneut übergeben wird. Bei der Wiederherstellung den schon persistierten Nachweis wiederverwenden: nicht bei jedem Seitenaufruf einen neuen erzeugen
Personenwechsel, Kontowechsel, Abmeldung: sofort reset(), dann das neue Profil, oder kein init(), wenn der Benutzer gegangen ist
Wiederherstellungsantworten verwerfen, die nach dem Wechsel ankommen: eine alte Antwort ist kein neues Login
In einer SPA eine einzige Instanz im Hauptlayout halten. Ein Routenwechsel startet das Provisioning nicht neu

Ist die Wiederherstellung nicht verfügbar, kann der Gast-Chat angeboten werden: reset(), dann init() ohne restore_id. Dieser Chat bleibt vom wiederhergestellten Verlauf getrennt.

Ein ungültiger, einem anderen Benutzer gehörender oder widerrufener Nachweis wird abgelehnt. Quoting24 wandelt ihn nicht in eine Gastsitzung um. Die Schaltfläche «Riprova» des Widgets fordert nicht von sich aus eine neue restore_id bei Ihrem Backend an. Die aktuelle Oberfläche ist Italienisch, deshalb ist diese Beschriftung Italienisch.

Beispiel für applyWidgetAuth und Abbau: Technische Integration.

reset() vergisst die Gastsitzung dieser Instanz und den im Browser gespeicherten Nachweis. Es widerruft restore_id auf dem Server nicht und beendet keine Sitzungen auf anderen Geräten. Die Website muss die anderen offenen Tabs aktualisieren.

Vorherige Unterhaltungen

Im wiederhergestellten Verlauf können geschlossene Chats als vorherige Unterhaltung erscheinen.

Sie zum Lesen zu öffnen öffnet die alte Unterhaltung nicht wieder
Neue Nachrichten bleiben in der aktiven Unterhaltung

Checkliste vor der Freigabe

[ ] Integrationsgeheimnis nur auf dem Server
[ ] external_user_id stabil und pro Person, identisch zwischen Provisioning und init()
[ ] restore_id vor der Antwort an den Browser persistiert und bei späteren Besuchen wiederverwendet
[ ] Derselbe Benutzer in einem zweiten Browser: derselbe Verlauf
[ ] Zwei Benutzer desselben Unternehmens: getrennte Verläufe
[ ] external_id und company_name im Bestand geprüft, ohne zu erwarten, dass sie den Chat wiederherstellen
[ ] Abmeldung oder Kontowechsel während des Abrufs: kein Chat des vorherigen Benutzers auf dem Bildschirm
[ ] Übergang Gast ↔ Wiederherstellung mit reset() dazwischen
[ ] Widerrufener oder ungültiger Nachweis: Fehler, ohne stillen Rückfall auf den Gast

Tests und Symptome: Integration prüfen · Problemlösung.