PubNub Developer Relations for PubNub [Français]

Posted on May 23

Comment modérer en toute sécurité le chat et les utilisateurs avec BizOps Workspace

Cet article fait partie d'une série d'articles qui traitent des capacités de gestion des données de PubNub, connues collectivement sous le nom de BizOps Workspace:

Comment gérer les utilisateurs et les canaux avec BizOps Workspace
Comment surveiller et modérer les conversations avec BizOps Workspace
Comment modérer en toute sécurité les conversations et les utilisateurs avec l'espace de travail BizOps

BizOps Workspace est un ensemble d'outils qui vous aide à gérer votre application. Cet article développe l'article précédent "Comment surveiller et modérer les conversations avec BizOps Workspace" pour montrer une application de chat sécurisée de bout en bout avec des capacités de modération manuelle, c'est-à-dire la capacité de surveiller les conversations en temps réel et de mettre en sourdine ou de bannir les utilisateurs.

Bien que cet article puisse être lu seul, je recommande fortement de lire l'article précédent "Comment surveiller et modérer les conversations avec BizOps Workspace" pour mieux comprendre le contexte des concepts discutés ici.

Qu'est-ce que le moniteur de canaux ?

Le moniteur de canaux permet aux modérateurs de chats de regarder des aperçus en direct des conversations qui se déroulent en temps réel sur plusieurs canaux. Si le modérateur repère quelque chose d'inquiétant, comme un utilisateur qui se comporte mal ou des messages offensants, il peut agir immédiatement pour résoudre le problème.

Le modérateur dispose d'une grande souplesse quant aux mesures à prendre :

Observer un utilisateur sans limiter ses droits d'accès
Modifier ou supprimer le message incriminé
Limiter la capacité de l'utilisateur à publier des messages(mettre en sourdine)
Limiter la capacité de l'utilisateur à lire ou à publier des messages(interdiction).

Toutes les fonctionnalités de la fonction "Surveiller" sont manuelles : examen manuel des messages, mise en sourdine manuelle des utilisateurs, etc. Cet article ne traite pas de la modération automatique.

Pour utiliser le Channel Monitor, vous devez avoir plusieurs fonctionnalités activées sur votre clé PubNub, en particulier le contexte de l'application et la persistance des messages au minimum. Pour plus de détails, veuillez consulter la section 'Keyset requirements for the Channel Monitor' dans l'article précédent.

Qu'est-ce que le PubNub Access Manager ?

Les*développeurs doivent se prémunir contre les utilisateurs qui tentent de contourner leur système de modération*, ce qui est possible grâce au gestionnaire d'accès PubNub.

Le gestionnaire d'accès vous permet de définir un ensemble de règles qui décrivent les permissions de l'utilisateur (ou des utilisateurs) spécifié(s) et les actions qu'il(s) peut(vent) effectuer sur les ressources spécifiées. Par exemple :

L'utilisateur dont l'ID est 123 a le droit de lire et d'écrire sur le canal 456.
Tous les utilisateurs dont l'ID correspond à l'expression régulière user-* peuvent lire sur n'importe quel canal dont l'ID correspond à l'expression régulière global-*.
L'utilisateur ayant l'ID 123 a le droit de mettre à jour les métadonnées du canal (c'est-à-dire le contexte de l'application).

Pour une liste complète des permissions, veuillez vous référer à la documentation à l'adresse https://www.pubnub.com/docs/general/security/access-control#permissions.

PubNub Access Manager est basé sur des jetons, et la façon la plus simple de le décrire est de parcourir le flux d'autorisation tel qu'il est montré dans la documentation et de fournir un contexte supplémentaire sur la façon dont ce flux est lié à la modération :

Tentative de connexion. Votre client s'authentifie auprès de votre serveur pour connecter vos utilisateurs à votre application. Après cette étape, votre serveur est certain de parler à un utilisateur enregistré de l'application et de savoir qui il est. Le client demande un jeton d'authentification PubNub Access Manager dans le cadre de son initialisation.
Demande d'autorisation. Le serveur traite la demande de jeton du client en invoquant l'API SDK 'grantToken()'. Quelques points à noter à propos de cette API : Elle ne peut être appelée qu'avec la clé secrète PubNub et, par conséquent, ne peut être invoquée qu'à partir d'un serveur ; elle est disponible pour tous nos SDK côté serveur ; et cette API acceptera des objets JSON pour définir les ressources et les permissions qui définissent l'accès de l'utilisateur (ou des utilisateurs).
Jeton retourné. PubNub accorde les permissions demandées à l'utilisateur ou aux utilisateurs demandés et renvoie un jeton d'authentification au serveur.
Jeton*transmis*. Votre serveur renvoie ensuite le jeton d'authentification au client demandeur initial.
Jeton défini. Le client peut spécifier ce jeton d'authentification lors de son initialisation ou à n'importe quel moment du cycle de vie de l'application grâce à la méthode setToken(). Il est essentiel de pouvoir mettre à jour le jeton à tout moment car les jetons expirent, mais un client devra également demander un nouveau jeton si le Channel Monitor met à jour ses autorisations (c'est-à-dire s'il est mis en sourdine ou banni).
Demande d'API autorisée. Tout appel ultérieur à PubNub sera désormais considéré comme autorisé. PubNub autorisera ou refusera toute demande d'API en fonction des permissions accordées à l'étape 2 et de la validité du jeton du client.

A quoi ressemble une solution de modération sécurisée ?

Vers la fin de l'article précédent, j'ai montré une démonstration de ce à quoi ressemblerait l'inhibition ou le bannissement du côté du client. Le SDK Chat contient des événements de modération qui indiquent à un client s'il a été mis en sourdine ou banni ; cependant, à part la mise à jour de l'interface utilisateur, cela n 'empêche pas le client de continuer à envoyer des messages même s'il a été mis en sourdine ou banni. Pour sécuriser la mise en sourdine ou le bannissement du client, vous devez révoquer les autorisations existantes du gestionnaire d'accès et lui en accorder de nouvelles pour refléter son nouveau statut de mise en sourdine ou de bannissement.

Prenons le scénario suivant : un utilisateur est mis en sourdine du canal "Musiques" :

Un utilisateur peut accéder à deux canaux, "films" et "comédies musicales", mais l'administrateur souhaite lui interdire l'accès au seul canal "comédies musicales".
Le modérateur coupe le son de l'utilisateur à l'aide du moniteur de canaux. En clair, il invoque l'API "setRestrictions()
L'application serveur reçoit la notification "mute" par le biais d'un événement de modération et révoque le jeton d'accès existant de l'utilisateur.
L'application cliente reçoit la notification "mute" associée au canal "musicals" par le biais d'un événement de modération.
L'application met à jour son interface utilisateur pour empêcher l'envoi d'autres messages. L'utilisateur peut contourner ce changement d'interface en modifiant le code JavaScript de la page, mais toute tentative d'envoi de messages échouera puisque son jeton d'authentification a été révoqué.
L'application demande un nouveau jeton d'authentification au serveur, comme décrit dans la section Gestionnaire d'accès ci-dessus. Le nouveau jeton d'authentification reflète les nouvelles autorisations de l'utilisateur, qui n'a plus que l'accès "lecture" au canal "comédies musicales".

L'article précédent décrivait les "Composants d'une solution de modération" et dressait la liste des API disponibles pour le client et le serveur à l'aide du graphique ci-dessous. Les API dont il est question dans les étapes ci-dessus sont également indiquées dans ce graphique.

L'exemple d'application Chat SDK

La même équipe d'ingénieurs chargée de développer le Channel Monitor et le Chat SDK a également créé un exemple d'application écrit en React Native qui utilise le Chat SDK.

L'exemple montre les capacités du SDK et les meilleures pratiques pour développer une application de chat réaliste et complète à l'aide de PubNub. Il est open source et fait partie du même dépôt GitHub qui contient le Chat SDK sous /samples/react-native-group-chat.

Cette application a récemment été mise à jour pour demander des jetons à un serveur Access Manager et pour demander un nouveau jeton lorsque les permissions de l'utilisateur changent, c'est-à-dire lorsqu'il est banni ou mis en sourdine d'un canal. Cette amélioration a été apportée depuis la rédaction de l'article précédent, alors assurez-vous d'obtenir la dernière source sur GitHub. Au moment de la rédaction de cet article, l'ID du commit git le plus récent est ae9dfa0.

Sécuriser la mise en sourdine et le bannissement des utilisateurs : Démonstration à l'aide de l'exemple d'application

Cette section décrit comment mettre en œuvre notre démo de bout en bout, en montrant la modération sécurisée du point de vue du client et du serveur.

Créer un jeu de clés PubNub

Je recommande de créer un nouveau jeu de clés PubNub pour exécuter cette démo comme suit :

Connectez-vous au portail d'administration et créez une nouvelle application ou un nouveau jeu de clés dans une application existante. Si nécessaire, vous pouvez trouver des instructions étape par étape sur notre page Comment créer des jeux de clés sur le portail d'administration.
Sur la page des jeux de clés, activez les options de configuration suivantes. Vous pouvez accepter les valeurs par défaut, sauf indication contraire :

App Context. Il stocke des métadonnées sur vos canaux et vos utilisateurs et est décrit plus en détail dans l'article précédent sur la"Gestion des utilisateurs et des canaux". Activez également les événements de métadonnées d'utilisateur, les événements de métadonnées de canal et les événements d'adhésion.
Persistance des messages. Ceci stocke l'historique de vos messages avec PubNub afin que l'administrateur puisse revoir et éditer les conversations.
Gestionnaire d'accès. Empêche l'accès non autorisé aux données et est nécessaire pour créer une solution de modération sécurisée.
Présence. Utilisé pour savoir si un utilisateur est en ligne ou hors ligne.

Enregistrez vos modifications.

Vous aurez besoin de la clé de publication, de la clé d'abonnement et de la clé secrète dans les étapes suivantes.

Créer l'exemple d'application

Comme décrit précédemment, l'application Chat SDK Sample est une application client multiplateforme écrite en React Native à l'aide du framework Expo.

Clonez et construisez l'application exemple en suivant les instructions données dans le readme de l'application. En particulier, assurez-vous que les prérequis sont installés, y compris yarn et Node.js. Le ReadMe parle d'utiliser XCode et iOS, mais vous pouvez également exécuter l'application sur un émulateur Android. Au moment où j'écris ces lignes, l'ID du commit git le plus récent est ae9dfa0.

Lorsque vous fournissez les clés Pub/Sub, utilisez les clés que vous avez générées à l'étape précédente. Si vous n'incluez pas les clés dans le fichier .env, l'application utilisera par défaut des clés de démonstration; vous pouvez désactiver cette logique à l'adresse https://github.com/pubnub/js-chat/blob/ae9dfa0/samples/react-native-group-chat/App.tsx#L60 pour éviter toute confusion.

Exécutez l'application. Le ReadMe vous indiquera de lancer yarn ios, mais vous pouvez également lancer yarn android ou yarn run start, ce dernier vous donnant un menu interactif.

Lorsque vous vous connectez, vous devriez voir l'avertissement suivant dans votre console :

C'est parce que le client n'a pas réussi à se connecter au serveur Access Manager, alors construisons-le.

Construire le serveur d'exemple de gestionnaire d'accès

L'exemple de serveur de gestion d'accès peut être trouvé à https://github.com/pubnub/js-chat/tree/master/samples/access-manager-api, c'est la même monorepo que l'application client discutée précédemment.

Ouvrez le fichier src/chatsdk.service.ts dans l'éditeur de votre choix et remplissez les champs publishKey, subscribeKey et secretKey. Les clés de publication et de souscription doivent correspondre à celles que vous avez utilisées pour construire l'application cliente, et la clé secrète est disponible depuis la page du jeu de clés de l'application sur le portail d'administration.

Depuis le répertoire REPO/samples/access-manager-api, exécutez yarn run start pour démarrer le serveur Access Manager, et vous devriez voir quelque chose comme ci-dessous :

Pour voir ce que fait le serveur Access Manager, regardez app.service.ts. Vous y verrez les structures de permission générées pour l'utilisateur demandeur et l'appel à chat.sdk.grantToken() pour appliquer ces permissions, renvoyant l'authKey générée au client appelant.

Il s'agit des permissions requises par l'application de démonstration, mais votre application aura probablement besoin de permissions différentes. Vous pouvez utiliser ce jeu de règles comme modèle de départ, mais lorsque vous créez le serveur Access Manager pour votre application, consultez https://www.pubnub.com/docs/chat/chat-sdk/build/features/users/permissions pour comprendre exactement quelles autorisations sont nécessaires pour quelles fonctionnalités du Chat SDK.

Relancez l'application client de démonstration et vous devriez maintenant pouvoir vous connecter sans erreur. Vous saurez que tout s'est bien passé lorsque vous obtiendrez un toast "Authkey refreshed".

Entamez une conversation entre deux clients.

Couper le son et bannir les utilisateurs à l'aide du moniteur de canaux

Important : si vous n'avez pas encore initié une conversation entre deux clients, faites-le maintenant. Les canaux sont créés dynamiquement par l'application de démonstration et ne s'affichent donc dans le moniteur de canaux qu'après le début de la conversation.

Notez que les mises à jour de l'interface utilisateur présentées ci-dessous, telles que la bannière "clé d'authentification rafraîchie" ou la fenêtre modale "utilisateur interdit", font partie de l'application de démonstration - votre application affichera ces informations à l'utilisateur par le biais de sa propre interface utilisateur.

Lancez le Channel Monitor en vous connectant au portail d'administration et en sélectionnant le jeu de clés que vous avez utilisé pour l'échantillon d'Access Manager et l'application client.
Allez à la section BizOps Workspace dans le panneau de navigation de gauche, et sélectionnez Channel Monitor. Si vous ne voyez pas la section BizOps Workspace, vous devez certainement mettre à niveau votre plan PubNub, mais n'hésitez pas à contacter notre support si vous avez des problèmes.
Vous serez invité à sélectionner vos canaux pour commencer la modération. Le nom du canal sera 1:1 user with USER_ID, où USER_ID est le nom d'utilisateur de la personne qui a initié la conversation.
Les messages du canal seront affichés en temps réel, y compris les messages précédents, si la persistance est activée sur votre clavier.

Mettez l'utilisateur en sourdine en appuyant sur le bouton du microphone situé à côté d'un message envoyé par cet utilisateur. Un message s'affiche sur l'appareil de l'utilisateur en sourdine pour l'informer que la clé d'authentification a été actualisée. Si vous tentez d'envoyer un message en tant qu'utilisateur en sourdine, vous verrez apparaître une boîte de dialogue indiquant que cette opération est interdite, bien que l'utilisateur en sourdine n'en soit pas affecté.

Rétablissez le son de l'utilisateur en appuyant à nouveau sur le bouton du microphone. Un message s'affiche sur l'appareil de l'utilisateur non mutique, vous informant que la clé d'authentification a été actualisée et que l'envoi de messages est désormais possible.

Bannissez l'utilisateur en appuyant sur le bouton de bannissement situé à côté du message envoyé par cet utilisateur et indiquez le motif du bannissement. Le motif est un texte libre, vous pouvez donc fournir toute information pertinente. La clé d'authentification sera rafraîchie et l'utilisateur sera renvoyé à l'écran de sélection du chat dans son application.

Si l'utilisateur tente d'accéder au canal banni, il recevra un message d'erreur :

Débanquez l'utilisateur en sélectionnant "Remove ban" sur le Channel Monitor. La clé d'authentification sera actualisée. L'utilisateur sera débanni et pourra à nouveau accéder à la discussion.

Résumé

Le développement d'une application de chat n'est que la première étape. Les défis les plus difficiles se présentent après le déploiement de cette application pour soutenir votre base d'utilisateurs croissante. BizOps Workspace est un ensemble d'outils conçus pour gérer tous les aspects de votre application de chat, simplifiant ainsi les défis postérieurs au lancement.

Bien que cet article se soit concentré sur la mise en sourdine et le bannissement d'utilisateurs en toute sécurité, nous continuons à développer les fonctionnalités de BizOps Workspace. Cet article s'est également concentré exclusivement sur le SDK Chat, mais le Channel Monitor peut également être configuré pour fonctionner avec n'importe lequel de nos SDK.

Si vous avez besoin d'aide ou de soutien, n'hésitez pas à contacter notre équipe de soutien spécialisée ou à envoyer un courriel à notre équipe de relations avec les développeurs à l'adresse devrel@pubnub.com.

Comment PubNub peut-il vous aider ?

Cet article a été publié à l'origine sur PubNub.com

Notre plateforme aide les développeurs à construire, fournir et gérer l'interactivité en temps réel pour les applications web, les applications mobiles et les appareils IoT.

La base de notre plateforme est le réseau de messagerie en temps réel le plus grand et le plus évolutif de l'industrie. Avec plus de 15 points de présence dans le monde, 800 millions d'utilisateurs actifs mensuels et une fiabilité de 99,999 %, vous n'aurez jamais à vous soucier des pannes, des limites de concurrence ou des problèmes de latence causés par les pics de trafic.