Configurer Slack dans OpenClaw

Une application Slack, c’est un manifeste, deux ou trois jetons et une décision sur la façon dont les événements atteignent la passerelle, et la documentation d’OpenClaw vous tend les manifestes à coller plutôt qu’une liste de portées à assembler. Voici l’installation, les deux manifestes, les chemins du mode Socket et du HTTP avec les jetons que chacun exige, l’option d’identité utilisateur qui publie en tant que personne réelle, et le modèle de jetons sur lequel la commande d’état rend compte.

Installation et manifestes

• L’extension s’installe avec la commande d’installation d’extensions pour le paquet Slack, qui l’enregistre et l’active puis ne fait rien tant que l’application Slack et les réglages du canal n’existent pas ; les manifestes de la page de configuration créent une installation à l’échelle de l’espace de travail, et une organisation Enterprise Grid utilise à la place le manifeste et le parcours dédiés à toute l’organisation.
• Vous créez l’application à partir d’un manifeste sur la page des applications Slack, choisissez votre espace de travail et collez l’un des deux manifestes : Recommandé correspond à l’ensemble complet des fonctions de l’extension, App Home, commandes slash, fichiers, réactions, épingles, messages de groupe et lectures d’emojis et de groupes d’utilisateurs, tandis que Minimal s’adresse aux espaces de travail dont la politique restreint les portées et couvre les messages privés, l’historique des canaux et des groupes, les mentions et les commandes slash mais abandonne les fichiers, les réactions, les épingles, les messages de groupe, la lecture des emojis et celle des groupes d’utilisateurs.
• Les deux manifestes déclarent un utilisateur bot toujours en ligne, un App Home avec un onglet de messages en écriture, une description Agent View avec trois invites suggérées, une commande slash au nom d’OpenClaw, et les événements de bot que l’extension écoute ; les variantes HTTP ajoutent l’URL de requête à la commande slash, aux abonnements d’événements et au bloc d’interactivité.
• Une fois l’application créée par Slack, le mode Socket exige un jeton d’application avec la portée d’écriture des connexions depuis les informations de base et le jeton OAuth de l’utilisateur bot depuis la page d’installation, tandis que le chemin HTTP exige le secret de signature des identifiants de l’application et le même jeton de bot.

L’application compagnon est une plomberie invisible : les autres membres de Slack voient des messages de l’humain qui a autorisé, pas d’un bot OpenClaw.

Mode Socket, HTTP, et publier en tant que personne

La configuration recommandée garde les jetons hors du fichier de configuration : exportez le jeton d’application et le jeton de bot dans l’environnement, écrivez un petit correctif qui active le canal, règle le mode sur socket et fait pointer chaque jeton vers une référence de secret d’environnement, lancez la commande de correctif de configuration d’abord à blanc puis pour de vrai, et démarrez la passerelle. Une fois le bloc Slack présent, les variables du jeton d’application et du jeton de bot servent aussi de repli d’identifiants pour le compte par défaut quand elles sont exportées dans l’environnement de la passerelle. Le chemin HTTP règle le mode sur http, référence le jeton de bot et le secret de signature et fixe le chemin de webhook, par défaut le chemin des événements ; les trois champs d’URL du manifeste, l’URL de la commande slash, l’URL de requête des événements et les URL d’interactivité, pointent tous vers le même point de terminaison parce que le schéma de Slack les nomme séparément alors qu’OpenClaw route par type de charge, et une commande slash sans son URL ne fait silencieusement rien en mode HTTP. Les installations HTTP multi-comptes donnent à chaque compte un chemin de webhook distinct pour que les enregistrements n’entrent pas en collision. L’identité utilisateur permet à OpenClaw de lire et de publier en tant que l’humain qui autorise l’application : le jeton utilisateur est l’identité agissante et une application compagnon transporte le trafic de l’API d’événements par le mode Socket ou une URL de requête sans avoir besoin d’un utilisateur bot. Cette application compagnon prend des portées de jeton utilisateur pour l’historique, la recherche de conversations, les personnes, la publication et l’ouverture de messages privés, s’abonne aux quatre événements de message au nom des utilisateurs plutôt que dans la seule liste du bot, choisit un transport, et est installée et autorisée en tant que l’humain voulu, dont le jeton OAuth utilisateur va dans la clé de jeton utilisateur avec la publication réglée sur utilisateur. Les messages privés et de groupe ne fonctionnent que par cet abonnement de portée utilisateur, parce qu’un bot ne peut ni rejoindre un message privé humain en tête-à-tête ni être inséré dans un message de groupe existant, et OpenClaw écarte les événements de message de portée utilisateur rédigés par l’humain résolu pour que ses propres messages ne déclenchent jamais d’auto-réponses.

Le modèle de jetons

• L’identité bot, par défaut, exige le jeton de bot plus le jeton d’application pour le mode Socket ou le jeton de bot plus le secret de signature pour le HTTP ; l’identité utilisateur exige le jeton utilisateur plus le jeton d’application ou le secret de signature et aucun jeton de bot ; le mode relais exige le jeton de bot plus une URL de relais, un jeton d’authentification et un identifiant de passerelle, sans jeton d’application ni secret de signature.
• Chaque clé de jeton accepte une chaîne en clair ou un objet SecretRef, les jetons de la configuration l’emportent sur le repli d’environnement, les trois variables d’environnement ne s’appliquent qu’au compte par défaut, et le jeton utilisateur est en lecture seule par défaut, si bien qu’en identité bot les actions et les lectures d’annuaire peuvent préférer un jeton utilisateur facultatif tandis que les écritures gardent le jeton de bot sauf si la lecture seule est désactivée ; avec la publication réglée sur utilisateur, lectures et écritures utilisent toujours le jeton utilisateur.
• L’inspection des comptes suit une source et un état par identifiant, disponible, configuré mais indisponible ou manquant, où configuré mais indisponible signifie que le compte est configuré par une référence de secret ou une autre source non inscrite dans le fichier que le chemin de commande ou d’exécution courant n’a pas pu résoudre ; le mode HTTP rapporte l’état du secret de signature, et le mode Socket rapporte les états des jetons de bot et d’application pour l’identité bot ou des jetons utilisateur et d’application pour l’identité utilisateur.

OpenClaw sur Slack est le billet du canal auquel cette configuration appartient, et Le contrôle d’accès Slack d’OpenClaw ce qu’il faut décider ensuite sur qui peut atteindre l’application.

Pourquoi deux transports

Le mode Socket n’exige aucune URL publique, ce qui en fait la valeur par défaut d’une passerelle sur un portable ou derrière un pare-feu ; le chemin HTTP convient à une passerelle qui a déjà une origine publique et laisse Slack vérifier chaque requête avec le secret de signature. Les extensions d’OpenClaw explique comment un canal arrive sous forme d’extension, et L’accès à distance d’OpenClaw comment une passerelle devient joignable quand vous voulez vraiment le chemin HTTP.

Sur Diali

Slack fait partie des canaux que Diali connecte depuis le tableau de bord, et la configuration d’exécution en est générée puis remplacée à chaque version, donc le modèle de jetons ci-dessus est le vocabulaire derrière cet écran plutôt qu’un correctif que vous écrivez. Slack sur Diali décrit le canal sur Diali et La sécurité chez Diali la frontière que partage chaque canal connecté.

• Collez un manifeste : Recommandé pour tout, Minimal pour les espaces stricts.
• Le mode Socket veut un jeton d’application ; le HTTP veut un secret de signature.
• Publier en tant que personne exige une application compagnon de portée utilisateur.