Aller au contenu
Documentation

Vérification d'identité : dire à l'agent qui sont vos visiteurs connectés

Signez les identifiants de vos utilisateurs sur votre serveur avec un secret HMAC pour qu'intoCHAT sache qui discute : conversations vérifiées, variables {{user.*}} dans les actions API et option pour réserver le chat aux visiteurs connectés.

La vérification d'identité permet à votre site d'indiquer à l'agent qui est un visiteur connecté, d'une façon que personne ne peut falsifier. Votre serveur signe l'identifiant de l'utilisateur avec un secret que seuls vous et intoCHAT connaissez, et votre page transmet l'identifiant et la signature au widget de chat.

Ce que cela apporte

Pour un visiteur vérifié :

  • La conversation affiche Verified: et l'identifiant de l'utilisateur dans Activity, avec le nom et l'e-mail transmis par votre page. L'export CSV contient une colonne Verified user ID, et les webhooks des leads, formulaires et réservations incluent un objet identity.
  • Les actions API côté serveur peuvent utiliser l'identifiant, l'e-mail, le nom et les métadonnées du visiteur comme variables, remplies par intoCHAT, jamais par l'IA.
  • Les gestionnaires d'actions côté client de votre page reçoivent le visiteur dans context.user.
  • L'IA apprend que le visiteur est vérifié, ainsi que son nom, pour pouvoir le saluer. Rien d'autre ; voir Ce que voit l'IA.

Vous pouvez aussi réserver le chat aux visiteurs vérifiés.

La vérification d'identité a besoin de la bulle de chat ajoutée par la balise script, car l'identité vient de votre page via le SDK JavaScript.

Mise en place

1. Générer un secret

  1. Ouvrez votre agent et allez dans l'onglet Share.
  2. Dans le bloc Identity verification, cliquez sur Generate secret.
  3. Copiez le secret et conservez-le sur votre serveur, par exemple dans une variable d'environnement nommée INTOCHAT_IDENTITY_SECRET.

Seuls le propriétaire du compte et les admins peuvent générer, afficher ou renouveler le secret. Les editors et les viewers voient s'il est défini, ainsi que ses quatre derniers caractères.

2. Signer l'identifiant sur votre serveur

Pour l'utilisateur connecté, calculez userHash : le HMAC-SHA256 de l'identifiant de l'utilisateur, avec le secret comme clé, écrit en hexadécimal minuscule. Signez exactement le texte que vous transmettrez comme userId.

Node.js :

import { createHmac } from "node:crypto";

const userHash = createHmac("sha256", process.env.INTOCHAT_IDENTITY_SECRET)
  .update(String(user.id))
  .digest("hex");

PHP :

<?php
$userHash = hash_hmac('sha256', (string) $user->id, getenv('INTOCHAT_IDENTITY_SECRET'));

Python :

import hashlib, hmac, os

user_hash = hmac.new(
    os.environ["INTOCHAT_IDENTITY_SECRET"].encode(),
    str(user.id).encode(),
    hashlib.sha256,
).hexdigest()

Insérez l'identifiant et le hash dans la page que vous envoyez à cet utilisateur.

3. Identifier le visiteur sur la page

Après le snippet, appelez IntoChat.identify à chaque chargement de page tant que le visiteur est connecté :

<script src="https://www.intochat.ai/api/embed.js" data-chatbot-id="YOUR_AGENT_ID"></script>
<script>
  window.IntoChat.identify({
    userId: "4711",
    userHash: "THE_HASH_FROM_YOUR_SERVER",
    name: "Ada Lovelace",         // optional
    email: "ada@example.com",     // optional
    metadata: { plan: "pro" }     // optional
  });
</script>

Les limites de chaque champ figurent sous identify. Le widget envoie l'identité avec chaque message, et le serveur d'intoCHAT vérifie la signature à chaque fois.

4. Réinitialiser à la déconnexion

Quand le visiteur se déconnecte, appelez :

IntoChat.reset();

L'identité est oubliée et un nouveau chat commence : la personne suivante sur ce navigateur ne voit donc pas la conversation précédente. Identifier un autre utilisateur démarre aussi un nouveau chat de lui-même. Un visiteur qui a discuté avant de se connecter garde cette conversation, qui devient alors vérifiée.

Réserver le chat aux visiteurs vérifiés

Activez Only verified visitors can chat dans le même bloc pour réserver le chat aux utilisateurs connectés :

  • Tant que votre page n'a pas identifié le visiteur avec une signature valide, le widget affiche à la place du champ de message un court avis qui l'invite à se connecter, dans la langue du widget.
  • L'API de chat refuse les messages sans identité valide, avec le motif identity_required : la règle s'applique donc aussi en dehors du widget.
  • Une iframe dans la page, un lien direct et la page d'aide ne peuvent identifier personne : ils n'affichent donc que l'avis. Les liens d'aperçu destinés aux prospects continuent de fonctionner, car ils ont leur propre chat.
  • Votre propre Playground continue de fonctionner : vous pouvez toujours tester l'agent.

Ce réglage a besoin d'un secret : générez-en un d'abord. Les editors peuvent l'activer ou le désactiver.

Variables dans les actions côté serveur

Une action API côté serveur peut utiliser ces variables n'importe où dans son URL, ses paramètres, ses en-têtes et son corps :

VariableRemplie avec
{{user.id}}L'identifiant vérifié de l'utilisateur
{{user.email}}L'e-mail transmis par votre page
{{user.name}}Le nom transmis par votre page
{{user.metadata.<key>}}Une valeur des métadonnées, par exemple {{user.metadata.plan}}
GET https://api.example.com/customers/{{user.id}}/orders

intoCHAT les remplit sur ses serveurs, uniquement à partir de l'identité vérifiée :

  • Pour un visiteur non vérifié, elles sont vides. Un paramètre ou un champ du corps vide est retiré de la requête.
  • L'IA ne les voit jamais et ne peut ni les choisir ni les modifier. Même si l'IA transmet une valeur qui ressemble à {{user.id}}, elle est envoyée en texte brut.
  • Send test request dans l'éditeur n'a pas de visiteur : elles y sont donc vides aussi.
  • Une variable qui constitue à elle seule une valeur du corps, comme {{user.metadata.seats}}, garde le type de la valeur : un nombre reste un nombre.

Toute autre variable {{user.…}}, comme {{user.phone}}, ne peut pas être enregistrée. Dans une action côté client, dont la requête est construite dans le navigateur du visiteur, ces variables restent vides ; votre gestionnaire reçoit plutôt le visiteur dans context.user.

Les visiteurs vérifiés deviennent des contacts

Chaque visiteur vérifié est conservé comme contact de l'agent, avec son identifiant d'utilisateur comme External ID, le nom et l'e-mail transmis par votre page, et comme attributs les clés de métadonnées qui sont des noms d'attribut valides (lettres minuscules, chiffres et tirets bas, en commençant par une lettre). Quand votre page transmet de nouvelles informations, le contact suit. Le contact est retrouvé uniquement par l'identifiant d'utilisateur : un visiteur vérifié n'est jamais fusionné avec un autre contact parce que les e-mails correspondent, et ne reçoit l'e-mail que si aucun autre contact ne l'a. Les actions côté serveur peuvent alors lire le contact, y compris les attributs que vous avez importés ou ajoutés via l'API, comme variables {{contact.*}}. Les visiteurs de Test as a signed-in visitor dans le Playground ne deviennent pas des contacts.

Ce que voit l'IA

L'IA apprend que le visiteur est connecté et vérifié, ainsi que le nom transmis par votre page, qu'elle peut utiliser pour le saluer. Elle ne reçoit jamais l'adresse e-mail, l'identifiant de l'utilisateur ni les métadonnées : elle ne peut donc ni les répéter ni être amenée à les révéler. Si vous voulez que l'agent en sache davantage, écrivez-le vous-même dans vos instructions.

Tester dans le Playground

Pour essayer les variables ou la salutation de l'agent sans vous connecter sur votre site, ouvrez le Playground et dépliez Test as a signed-in visitor au-dessus du chat. Saisissez un User ID et, si vous le souhaitez, un Name, un Email et des Metadata sous forme d'objet JSON, par exemple {"plan": "pro", "seats": 5}. Les mêmes limites que sur votre site s'appliquent ; voir Limites. Tant qu'une valeur doit être corrigée, un message rouge indique laquelle, et le Playground discute comme un visiteur anonyme.

Avec un identifiant d'utilisateur renseigné, vos messages dans le Playground comptent comme vérifiés :

  • Les actions côté serveur reçoivent ces valeurs comme variables {{user.*}}.
  • L'IA apprend que le visiteur est vérifié, ainsi que son nom, comme décrit dans Ce que voit l'IA.
  • La conversation du Playground enregistre l'utilisateur : elle affiche donc Verified dans l'onglet Conversations.

Aucune signature n'est nécessaire, car vous êtes connecté à intoCHAT. L'identité de test n'est acceptée que depuis le Playground de votre tableau de bord, de la part du propriétaire, d'un admin ou d'un editor ; les viewers ne peuvent pas l'utiliser, et le widget de chat, les liens et l'API REST l'ignorent. Les visiteurs de votre site ont toujours besoin d'une signature valide. Le Playground n'est jamais refusé par Réserver le chat aux visiteurs vérifiés, avec ou sans identité de test.

Une conversation garde le premier utilisateur vérifié qu'elle voit : appuyez donc sur Reset avant de tester en tant qu'autre utilisateur.

Le secret

  • Reveal affiche de nouveau le secret actuel, pour le propriétaire et les admins.
  • Rotate crée un nouveau secret, après confirmation. L'ancien cesse de fonctionner immédiatement : tant que votre serveur ne signe pas avec le nouveau secret, chaque visiteur compte comme non vérifié et, si Only verified visitors can chat est activé, personne ne peut discuter.
  • Le secret est stocké chiffré. Dupliquer un agent ne copie ni le secret ni ce réglage.

Limites

  • Un seul secret par agent. Avec plusieurs agents sur une même page, chacun ne vérifie que les signatures faites avec son propre secret.
  • Une signature fausse ou absente n'est jamais présentée au visiteur comme une erreur : il discute simplement sans être vérifié, sauf si le chat est réservé aux visiteurs vérifiés.
  • Une conversation appartient au premier utilisateur vérifié dans celle-ci. Si un autre utilisateur vérifié écrit dans la même session, sans le nouveau chat que identify démarre normalement, ses messages sont traités comme non vérifiés.
  • Un identifiant d'utilisateur compte jusqu'à 200 caractères, un nom jusqu'à 100, un e-mail jusqu'à 254, et les métadonnées jusqu'à 20 clés et 2 Ko.
  • L'identité n'est pas vérifiée quand un visiteur rouvre un chat précédent depuis la liste de son navigateur ; Réinitialiser à la déconnexion vide cette liste.

Voir en Markdown