Introduction

Ces dernières années, nous avons assisté à un essor incroyable des plateformes d'événements en ligne où un utilisateur achète un billet et participe à un événement, un concert ou une leçon privée avec un professeur à partir de son navigateur. Ces plateformes doivent s'assurer que seuls les utilisateurs autorisés peuvent participer à l'événement ou à la leçon et ont besoin d'un contrôle précis du temps pendant lequel les utilisateurs sont connectés à une session spécifique. La meilleure façon de mettre cela en œuvre est de disposer d'un mécanisme qui notifie au serveur d'application les connexions et les flux publiés dans une session sous la forme d'un webhook en temps réel.

Surveillance de session offre un moyen fiable et sécurisé de surveiller les connexions dans une application Video API de Vonage. L'ajout de la surveillance de session offre aux développeurs une couche de sécurité supplémentaire pour surveiller l'activité du client du côté serveur, vérifier chaque connexion à une session vidéo et enregistrer chaque action pour des raisons de conformité.

Principaux Concepts

Grâce aux webhooks de suivi de session, les développeurs peuvent recevoir des rappels d'événements de session en temps réel et surveiller l'activité de leur session depuis leur serveur d'application. L'infrastructure OpenTok peut envoyer des requêtes HTTP pour toutes les connexions établies (et détruites) et les flux créés (et détruits).

Décortiquons les événements disponibles :

• connectionCreated: déclenché lorsqu'un client se connecte à une session

• connectionDestroyed: déclenché lorsqu'un client se déconnecte d'une session

• streamCreated: déclenché lorsqu'un client publie un flux dans une session

• streamDestroyed: déclenché lorsqu'un client dépublie un flux à partir d'une session

Chaque événement a une charge utile. Analysons l'événement connectionCreated à titre d'exemple :

{
    "sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
    "projectId": "123456",
    "event": "connectionCreated",
    "timestamp": 1470257688309,
    "connection": {
        "id": "c053fcc8-c681-41d5-8ec2-7a9e1434a21e",
        "createdAt": 1470257688143,
        "data": "TOKENDATA"
    }
}

La charge utile de l'événement contient des données qui peuvent être utilisées pour créer la logique commerciale dont la plate-forme a besoin. Par exemple, nous pouvons utiliser les éléments connectionId et timestamp pour calculer le temps de connexion d'un utilisateur spécifique. Dans les prochaines sections, nous aborderons des exemples plus détaillés.

Limiter le temps de connexion des utilisateurs dans une session

Supposons que nous ayons un site web éducatif où les étudiants paient pour des leçons d'une heure avec un professeur. Une fois l'heure écoulée, l'utilisateur doit être déconnecté de la session. Comment pouvons-nous mettre cela en œuvre à l'aide de la surveillance de session ?

Pour ce cas d'utilisation, nous avons besoin d'écouter les messages connectionCreated et connectionDestroyed . La logique sera la suivante :

• Démarrer le minuteur de session uniquement si les connexions sont supérieures ou égales à deux

• Vérifier toutes les 5 secondes le temps écoulé

• À l'expiration du délai, déconnexion forcée des utilisateurs.

Voyons le code :

app.post('/session-monitoring', async (req, res) => {
   const { sessionId, projectId, event, timestamp, connection } = req.body;
   const roomName = sessions[sessionId];
    switch (event) {
            case "connectionCreated":
                // There are at least 2 users
if (session.connections && session.connections.length > 1) {
            session.interval = setInterval(() => {
                const now = new Date().getTime();
                session.connections.sort((x, y) => { return y.timestamp - x.timestamp }) // Make sure they are ordered by latest connections;
                if ((now - session.connections[0].timestamp) > limitedTimeRoomMinutes * 60 * 1000) { 
                    // time has expired, let's disconnect them
                    for (let i = 0; i < session.connections.length; i += 1) {
                        opentok.forceDisconnect(sessionId, session.connections[i].connection.id);
                    }
                    clearInterval(session.interval)
                }
            }, roomInterval.intervalValue)
        }
                break;
       case "connectionDestroyed":
                break;
            case "streamCreated":
                break;
            case "streamDestroyed":
                break;
            default:
                console.warn("Not handled case, this should not happen");
})

Limiter la taille d'une session

Supposons que nous souhaitions limiter la taille d'une session, par exemple à un seul utilisateur. Si quelqu'un d'autre se connecte, le code va l'expulser. Voyons le code :

switch (event) {
            case "connectionCreated":
session.connections = [...session.connections, { connection, timestamp }];
             break;
            case "connectionDestroyed":
               if (session && session.connections) {
        for (let i = 0; i < session.connections.length; i += 1) {
            if (session.connections[i].connection.id === connection.id) {
                session.connections.splice(i, 1);
                break;
            }
        }
    	  }
              break;
}

if (session.connections && session.connections.length > 2) {
      opentok.forceDisconnect(sessionId, connection.id);
 }

Dans ce cas, le code suit le nombre de connexions à l'intérieur d'une session. Si le nombre de connexions est supérieur à 2, il va déconnecter l'utilisateur qui a essayé de se connecter. En suivant cette approche, la troisième connexion pourra se connecter pendant quelques secondes et une fois que le serveur aura reçu le crochet connectionCreated l'utilisateur sera déconnecté. Il est possible d'améliorer ce comportement en ne laissant même pas le troisième utilisateur se connecter à la session. Lorsque le troisième utilisateur demande les informations d'identification pour se joindre à la session, le serveur peut vérifier le nombre de connexions dans la session. S'il y a déjà deux connexions, le serveur n'enverra pas les informations d'identification au troisième utilisateur et affichera un message d'erreur :

app.get('/room/:room', (req, res) => {
    const roomName = req.params.room;
    if (sessions[roomName]) {
       if (sessions[roomName].connections.length >= 2) {
       renderRoom(res, null,null,null, roomName);	
} else {
  const sessionId = sessions[roomName].sessionId;
        const dataToken = opentok.generateToken(sessionId);
        renderRoom(res, dataToken.apiKey, sessionId, dataToken.token, roomName);
}
        
    } else {
        setSessionDataAndRenderRoom(res, roomName);
    }
});

Autres cas d'utilisation

Nous avons vu les deux principaux cas d'utilisation de la surveillance des sessions, mais il en existe bien d'autres, comme le fait d'autoriser uniquement les utilisateurs autorisés à rejoindre la session ou de limiter le type de flux qu'un utilisateur peut publier.

Permettre aux seuls utilisateurs autorisés de participer à la session

Dans le domaine des événements en ligne, il est important que seuls les utilisateurs autorisés puissent participer aux événements. Par exemple, seuls les détenteurs de billets peuvent participer à une conférence spécifique. Nous disposons d'une liste d'utilisateurs qui ont payé pour l'événement et qui sont autorisés à le rejoindre. Comment pouvez-vous interpoler ces données avec la surveillance des sessions ?

Lorsque vous créez un jeton pour rejoindre une session, vous pouvez ajouter des métadonnées. Les métadonnées seront disponibles sur le webhook des événements de connexion. Lorsque vous recevez l'événement connectionCreated vous pouvez vérifier l'identité de la connexion et comparer les données avec celles des utilisateurs autorisés dans la base de données. Si l'utilisateur n'est pas autorisé à rejoindre la session, le serveur le déconnectera de force.

Autoriser uniquement des flux spécifiques à publier des partages d'écran

Jusqu'à présent, nous n'avons vu que l'utilisation des événements de création et de destruction de connexion, nous allons donc donner un exemple de l'utilisation de l'événement de création ou de destruction de flux. Les événements de flux contiennent des données supplémentaires telles que name et videoType du flux. En utilisant ces dernières, nous pouvons mettre en œuvre un cas d'utilisation dans lequel seuls les utilisateurs autorisés peuvent partager leurs écrans. Prenons l'exemple d'une société de conseil financier, où nous voulons que seul le conseiller financier puisse partager son écran et non le client (pour éviter de partager des informations sensibles). Lorsque le serveur reçoit l'événement streamCreated il peut vérifier si videoType est un écran et si l'utilisateur est autorisé à partager l'écran. Si ce n'est pas le cas, il peut dépublier le flux de la session.

Comment enregistrer les webhooks ?

Les événements de session et les informations de mise à jour de l'état des archives peuvent tous être enregistrés dans des points de terminaison HTTP au sein de votre serveur. Chaque fois qu'une activité enregistrée se produit, une requête HTTP est émise par l'infrastructure OpenTok vers votre point de terminaison.

Pour enregistrer un rappel :

1. Visitez la page de votre compte API Video de Vonage.

2. Sélectionnez le projet OpenTok pour lequel vous souhaitez enregistrer un rappel.

3. Définir l'URL de rappel dans la section Suivi de session

Il est très important de noter que si, dans un délai de 30 minutes, il y a plus de 50 échecs de livraison d'événements (c'est-à-dire si nous ne recevons pas de réponse 200 lorsqu'une requête HTTP est envoyée à votre URL de rappel), nous désactiverons le transfert d'événements pour le suivi de session. Nous vous enverrons un courrier électronique si cela se produit

Exemple d'Applications

La surveillance des sessions de l'API vidéo Video API Session Monitoring présente deux des exemples mentionnés ci-dessus :

1. Limiter le temps de connexion des utilisateurs dans une session sur la page locahost:5000/room/limited-time-room, le serveur démarre un minuteur lorsqu'il y a au moins 2 connexions (2 utilisateurs). La minuterie vérifie toutes les 5 secondes le temps restant pour la session. Lorsque le temps est écoulé, le serveur déconnecte de force les utilisateurs de la session à l'aide de la commande forceDisconnect pour forcer la déconnexion des utilisateurs de la session.

2. Limiter la taille d'une session : sur la page locahost:5000/room/one-to-onele serveur n'autorisera que deux utilisateurs (connexions) connectés à la salle. S'il y a une troisième connexion, le serveur la déconnecte immédiatement.

Conclusion

Le contrôle de session est une fonction couteau suisse qui permet d'ajouter de la sécurité et d'implémenter des contrôles côté serveur à votre application Video. Pour voir en action certains des exemples décrits dans ce billet de blog, jetez un coup d'œil au repo Github : https://github.com/nexmo-se/video-api-session-monitoring. Ce billet de blog montre quelques cas d'utilisation mis en œuvre avec les webhooks de surveillance de session. Le fait de disposer des données relatives aux connexions et aux flux côté serveur offre aux développeurs la possibilité de surveiller, de stocker et de réagir aux événements en temps réel.

Si vous avez essayé cette fonction et que vous avez des questions à ce sujet, rejoignez notre Communauté Vonage Slack ou envoyez-nous un message sur sur Twitter.