Notifications

Libre WebUI conserve une boîte de réception de notifications durable et propre à chaque utilisateur. L’activité de l’équipe — mentions, messages directs, partages, échecs d’automatisations et rappels de calendrier — atteint ainsi les personnes même lorsque la page concernée est fermée.

La boîte de réception

Les notifications sont d’abord des lignes de base de données : leur titre et leur corps sont chiffrés au repos, leur nombre est limité à 500 par utilisateur (les plus anciennes sont élaguées) et une clé source facultative permet de les dédupliquer. Une publication répétée est ainsi regroupée en une seule entrée au lieu de faire sonner la cloche sans cesse. La surface REST permet de les répertorier, de compter les éléments non lus, de les marquer comme lus (une notification ou toutes) et de les supprimer.

La livraison en direct emprunte le flux d’événements durable propre à l’utilisateur notify:<userId> via GET /api/notifications/events (SSE). L’identité du flux provient de la session authentifiée, jamais d’une entrée du client, et la boîte de réception SQL reste la source de vérité : un événement manqué est récupéré en relisant la liste, et non en rejouant le flux.

Origine des notifications

Type	Déclenchement
channel-dm	Quelqu’un vous envoie un message direct
channel-mention	Quelqu’un vous @mentions dans un canal ou répond à votre message
channel-invite	Vous êtes ajouté à un canal
share	Quelqu’un partage une ressource avec vous
automation-failed	L’une de vos automatisations échoue (sauf si elle a désactivé cette option)
calendar-reminder	Un événement avec un délai de rappel atteint l’heure prévue
work-run-finished	L’un de vos agents Work recrutés termine une exécution
work-run-attention	Un agent recruté s’arrête pour demander une intervention ou rencontre une erreur
work-takeover	Un agent Work vous demande de prendre le contrôle de son écran
work-approval	Une exécution Work attend que vous approuviez une action à effet
system	Annonces au niveau de l’instance

Les notifications sont toujours publiées uniquement à l’utilisateur concerné ; mentionner le nom d’un utilisateur qui n’est pas membre du canal ne produit rien.

Webhooks sortants

Les administrateurs peuvent enregistrer des cibles de webhook qui reçoivent les événements de l’équipe.

• Sortie protégée. Les cibles sont soumises à la même politique de destination que les serveurs d’outils : URL exacte, aucune redirection, aucune adresse privée ou locale au lien, sauf si l’administrateur a explicitement ajouté un hôte à TOOLS_PRIVATE_NETWORK_ALLOWLIST. Les noms d’hôtes sont résolus et revérifiés à chaque livraison.
• Signature. Lorsqu’un secret est configuré, chaque livraison porte X-Libre-Signature: sha256=<hmac>, calculé sur le corps exact.
• Caviardage. L’enveloppe contient le type d’événement, le type de notification, le titre, les identifiants et les horodatages. Les corps des notifications, le contenu des messages, les invites et les documents ne quittent jamais l’instance.
• Durabilité. Les livraisons s’exécutent comme des tâches durables avec un nombre limité de tentatives ; une réponse 5xx du destinataire déclenche une nouvelle tentative, tandis qu’une réponse 4xx est considérée comme son verdict et clôt la livraison.
• Portée. Chaque cible s’abonne à des types de notifications précis (ou à *).

Notifications push du navigateur

Paramètres → Notifications enregistre ce navigateur pour Web Push, afin que les mentions, partages, rappels et tâches terminées atteignent l’appareil même lorsque l’onglet est fermé. La mise en œuvre est standard et autonome :

• VAPID (RFC 8292). Le serveur signe chaque livraison avec une paire de clés ES256, générée une fois et stockée sous forme chiffrée, ou fixée au moyen de VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY (VAPID_SUBJECT définit la déclaration de contact). Aucune bibliothèque push ni aucun compte de service tiers n’intervient, en dehors du point de terminaison push du fournisseur du navigateur.
• Charges utiles chiffrées (RFC 8291). Chaque message est chiffré pour les clés propres à l’appareil avec aes128gcm avant de quitter l’instance ; le service push relaie un texte chiffré qu’il ne peut pas lire.
• Par appareil et liée à la session. Un abonnement appartient au navigateur qui l’a créé et à la session d’authentification de ce navigateur : se déconnecter de la session (ou « déconnecter les autres sessions ») supprime également son enregistrement push. Les points de terminaison sont stockés sous forme chiffrée avec un jeton de recherche à clé et doivent être des destinations HTTPS publiques, selon les mêmes règles de sécurité des sorties que les webhooks.
• Durabilité. Les livraisons push s’exécutent comme des tâches durables avec un nombre limité de tentatives ; si un service push signale la disparition de l’abonnement (404/410), celui-ci est supprimé.
• La charge utile contient le titre de la notification, son corps facultatif, son type et son lien cible, avec le même niveau de caviardage que la boîte de réception.

Les notifications push exigent l’application de production (le service worker ne s’y enregistre que dans ce cas) et une origine sécurisée. Le même service worker fournit l’enveloppe hors ligne et la possibilité d’installer l’application : le manifeste rend Libre WebUI installable, les navigations se rabattent sur l’enveloppe mise en cache hors ligne et les ressources de build hachées sont mises en cache de façon immuable. Le trafic de l’API n’est jamais mis en cache.

Frontières

• Les préférences utilisateur par type ne sont pas encore implémentées ; les automatisations respectent leur propre réglage de notification et quitter un canal interrompt ses notifications.