Je gère un petit forum et trois autres sites web, et je constatais toujours la même chose. Les gens étaient heureux de discuter dans le chat une fois sur le forum, mais personne ne va sur un forum pour poser une question rapide. Ils la posent là où ils se trouvent déjà, ou ils ne la posent pas du tout.
J’ai donc créé un plugin qui place le chat du forum sur ces autres sites. Une seule balise de script, et une bulle d’angle apparaît. Les visiteurs se connectent avec leur compte forum existant, via l’écran de connexion du forum lui-même, et discutent dans les mêmes canaux qu’ils verraient sur le forum. Les messages qu’ils envoient arrivent dans le chat du forum comme n’importe quel autre message, car c’est bien le cas.
Dépôt : GitHub - capodieci/discourse-chat-bridge: Allows to install discourse chat as a plugin in other websites · GitHub (MIT)
<script src="https://forum.example.com/chat-bridge/widget.js"
data-site-key="your-site-key" defer></script>
Pourquoi c’est un plugin plutôt qu’un service
J’ai commencé par concevoir un pont externe qui communiquerait avec Discourse via l’API, puis j’ai lu le code source. Cela a complètement changé la conception, et les raisons peuvent être utiles à quiconque envisage quelque chose de similaire.
Le plugin de chat enregistre exactement une portée API granulaire, create_message. Tout au-delà de la publication, comme la lecture des canaux, la récupération de l’historique ou l’ouverture d’un message direct, nécessite une clé de portée globale, et une clé de portée globale pour chaque utilisateur représente un grand tas d’identifiants à gérer. Les limites de débit par défaut sont de 60 requêtes par minute sur le bac admin et 20 sur le bac utilisateur, ce qu’un client de chat consomme sans même essayer. Et les webhooks de chat transportent quatre événements de message et rien d’autre, donc les réactions, la présence et l’état de lecture ne sont tout simplement pas disponibles pour être transférés.
Chacun de ces problèmes disparaît lorsque le code s’exécute à l’intérieur de Discourse et peut poser une question directement à Guardian. Pas de clés, pas de plafond de limite de débit, et une source de vérité unique plutôt qu’un cache qui peut diverger du forum.
Ce qui fonctionne
Les canaux, l’historique des messages, l’envoi, les messages directs avec recherche de personnes, et les messages vocaux enregistrés dans le navigateur. Les messages vocaux apparaissent comme un lecteur audio normal pour les membres lisant le chat du forum lui-même, et non comme un lien de téléchargement, ce qui a demandé un peu de soin pour être fait correctement.
Chaque site web reçoit sa propre couleur d’accent, son angle et son titre de panneau, afin que trois sites puissent ressembler à trois produits différents plutôt qu’à trois copies du même widget. Les visiteurs obtiennent un son de notification qu’ils peuvent désactiver, un mode clair ou sombre, et la possibilité d’activer le mode silencieux d’une conversation, ce qui s’écrit dans leur adhésion Discourse réelle et les suit donc jusqu’au forum.
Tout est rendu à l’intérieur d’un Shadow DOM. Cela fonctionne sur des pages que je ne contrôle pas, et le CSS des deux côtés ne devrait pas pouvoir casser l’autre.
Ce qui ne fonctionne pas, et pourquoi
Il n’y a pas d’appels vocaux ou vidéo. C’est délibéré et hors du périmètre.
La livraison n’est pas instantanée. Les messages arrivent en environ trois secondes pendant que le panneau est ouvert. Cela mérite une explication, car Discourse publie bien des événements de chat sur MessageBus et cela a l’air de fonctionner directement.
Un navigateur sur un autre domaine ne peut pas s’authentifier sur le point d’accès MessageBus. Sa politique CORS autorise quatre en-têtes de requête et aucun d’entre eux ne transporte un jeton porteur, et la route par paramètre de requête vers l’authentification de Discourse est restreinte aux points d’accès RSS et calendrier. Le seul en-tête qui fonctionne, X-Shared-Session-Key, se résout en un UserAuthToken et authentifie donc toute requête le portant, et non seulement celles de MessageBus. Donner cela à une page d’intégration transformerait un trou de cross-site scripting sur un site marketing en une prise de contrôle complète du compte du forum. Trois secondes est le meilleur compromis.
Il existe une route plus sûre vers le temps réel documentée dans le dépôt, utilisant un canal MessageBus dont le nom indevinable est lui-même la capacité, limité à une session de widget plutôt qu’au compte de l’utilisateur. Je ne l’ai pas construit. Si quelqu’un le veut, le raisonnement est dans docs/decisions.md.
La chose à comprendre avant d’installer
L’enregistrement d’un site web accorde à ce site un accès cross-origin à votre forum portant les identifiants de vos membres. Ce n’est pas un effet secondaire, c’est le mécanisme.
Si un site que vous avez enregistré est compromis, un attaquant capable d’exécuter du JavaScript dessus peut agir en tant que n’importe quel membre qui le visite. Pas seulement dans le chat. Tout ce que ce membre pourrait faire sur le forum.
Enregistrez donc uniquement des sites que vous contrôlez. Enregistrer le site d’un partenaire ou d’un client signifie accepter leur sécurité comme la vôtre. Le plugin le dit sur la page d’administration à côté du champ où vous tapez l’origine, plutôt que dans un document que personne n’ouvre, et SECURITY.md passe en revue ce que le plugin fait pour limiter le rayon d’explosion et ce qu’il ne fait délibérément pas.
Installation
Ajoutez-le à votre définition de conteneur et reconstruisez une fois :
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone --depth 1 https://github.com/capodieci/discourse-chat-bridge.git
env:
DISCOURSE_ENABLE_CORS: true
Puis activez chat_bridge_enabled dans Administration, Paramètres, et tout le reste se trouve sur une seule page à /chat-bridge/admin, où vous ajoutez un site web et il vous donne la balise de script.
Deux notes qui sauveront quelqu’un d’une après-midi. Les messages vocaux ont besoin de formats audio dans authorized_extensions, qui par défaut n’en contient aucun, donc la page d’administration vous dit exactement lesquels manquent. Et chat_allowed_groups est par défaut au niveau de confiance 1, donc les tout nouveaux comptes ne peuvent pas discuter jusqu’à ce qu’ils l’obtiennent, ce que le widget explique plutôt que d’échouer silencieusement.
Compatibilité
Testé contre Discourse 2026.9.0 et 2026.8.0, et en usage de production sur un forum.
Cela s’appuie sur des objets de service de chat qui ne sont pas une API publique, donc une version de Discourse peut les déplacer. Le dépôt inclut un script de pré-vol en lecture seule qui affirme que chacun d’entre eux existe toujours et rapporte en secondes plutôt qu’à la première requête. Utile à exécuter après une mise à niveau.
Ce que je voudrais
Que quelqu’un l’installe sur un forum qui n’est pas le mien et me dise ce qui a cassé. Tout jusqu’ici est vérifié contre un seul Discourse, sur un seul serveur, par une seule personne, et c’est la chose la plus faible à ce sujet.
Je voudrais aussi entendre de la part de quiconque connaît une meilleure réponse au problème de MessageBus que celle sur laquelle je me suis arrêté.
