Application Slack

Votre agent dans un espace de travail Slack, qui répond dans le fil. Chaque événement est vérifié avant de devenir une exécution.

Une connexion Slack sert un seul agent, et répond avec la version épinglée sur le déploiement Slack live de cet agent. Les mentions et les messages directs arrivent par l'Events API de Slack, l'agent répond dans le fil, et la conversation reste là où l'équipe travaille déjà. La prise en charge de Slack fait partie de l'édition Community.

Connecter un espace de travail

Rikoo est auto-hébergé : il n'existe pas d'application Rikoo centrale à installer, chaque entreprise déclare sa propre application Slack. Slack doit pouvoir joindre votre instance à une adresse HTTPS publique.

1. Créez une application Slack pour votre espace de travail, installez-la, et déposez son jeton de bot (xoxb-…) et son secret de signature sur l'écran Secrets.
2. Sur la fiche de l'agent, ouvrez l'onglet Deploy et cliquez sur Gérer la connexion dans la carte Slack. Choisissez Jeton manuel, sélectionnez les deux secrets et enregistrez.
3. La fenêtre affiche alors l'adresse à déclarer dans Slack (Event Subscriptions, Request URL). Elle est propre à cette connexion. Renseignez-la dans votre application, avec les portées et les événements du manifeste que fournit la fenêtre (Manifeste d’app, prêt à coller).
4. Cliquez sur Vérifier la connexion. Le worker contrôle le jeton, et le statut passe à connected, avec le nom de l'espace de travail.
5. Invitez le bot dans les canaux où il doit répondre (/invite @votre-bot). Slack ne livre rien d'un canal dont le bot n'est pas membre.
6. Avec l'environnement live sélectionné, activez l'interrupteur Slack de l'onglet Deploy.

La fenêtre ne détient que des références vers les secrets du coffre, et le serveur d'API ne les déchiffre jamais. Un bot parle au nom d'un seul agent : un second agent demande une seconde application Slack.

Slack n'est servi que depuis live

Un espace de travail n'a pas d'environnement de test à lui : un déploiement Slack test est donc sans effet. Ce qui répond dans Slack est toujours la version épinglée sur live, celle qu'un contrôle de publication a jugée quand les contrôles sont en service. Essayez une version dans le Playground.

À qui répond le bot

Le déploiement Slack porte le comportement du bot. Par défaut, le bot répond aux mentions dans les canaux et aux messages directs, dans tous les canaux où il a été invité, et ignore les autres bots : deux bots qui se répondent bouclent indéfiniment. Une fois que le bot a répondu dans un fil, le fil continue sans nouvelle mention.

Vérifié à l'entrée

Chaque requête est vérifiée

Slack signe chaque livraison. Le point d'accès public accuse réception aussitôt et remet le corps brut au worker, qui vérifie la signature et une fenêtre d'horodatage de cinq minutes, puis écarte les événements déjà vus. Une requête qui échoue à ce contrôle ne devient jamais une exécution. Le point d'accès répond de la même façon que la connexion existe ou non : il n'apprend rien à qui le sonde.

Une note sur la limitation de débit

Le point d'entrée n'est jamais limité par l'adresse appelante. Chez Slack, une adresse porte le trafic de milliers de clients : la limiter couperait du trafic légitime, et Slack marque comme défaillant un point d'accès qui répond 429 à répétition. La limite est indexée sur la connexion appelée, si bien qu'un identifiant forgé n'épuise que son propre budget.

Ce que reçoit l'agent

Du texte, et les fichiers déposés dans la conversation. Les fichiers passent par la même politique d'admission que le widget et l'API, avec les mêmes types et les mêmes plafonds de taille. Un fichier refusé est signalé à l'agent, qui le dit à l'utilisateur. Tout ce qui vient de Slack est du contenu non fiable et est encadré comme tel : un message d'un collègue est une donnée, pas une instruction. Les réponses sont du texte seul, sans boutons interactifs.