Einführung

In den letzten Jahren haben wir einen unglaublichen Anstieg von Online-Veranstaltungsplattformen erlebt, bei denen ein Nutzer ein Ticket kauft und über seinen Browser an einer Veranstaltung, einem Konzert oder einer Privatstunde mit einem Lehrer teilnimmt. Diese Plattformen müssen sicherstellen, dass nur autorisierte Benutzer an der Veranstaltung oder dem Unterricht teilnehmen können, und sie müssen die Zeit, in der die Benutzer mit einer bestimmten Sitzung verbunden sind, genau kontrollieren. Dies lässt sich am besten mit einem Mechanismus realisieren, der den Anwendungsserver über Verbindungen und Streams informiert, die in Form eines Echtzeit-Webhooks in einer Sitzung veröffentlicht werden.

Sitzungsüberwachung bietet eine zuverlässige und sichere Möglichkeit zur Überwachung von Verbindungen in einer Vonage Video API Application. Das Hinzufügen der Sitzungsüberwachung bietet Entwicklern eine zusätzliche Sicherheitsebene, um Client-Aktivitäten von der Serverseite aus zu überwachen, jede Verbindung zu einer Video-Sitzung zu verifizieren und jede Aktion aus Compliance-Gründen zu protokollieren.

Wichtigste Concepts

Mit den Webhooks für die Sitzungsüberwachung können Entwickler Echtzeit-Sitzungsereignis-Callbacks empfangen und ihre Sitzungsaktivitäten von ihrem App-Server aus überwachen. Die OpenTok-Infrastruktur kann HTTP-Anfragen für alle hergestellten (und zerstörten) Verbindungen und erstellten (und zerstörten) Streams senden.

Schauen wir uns die verfügbaren Ereignisse an:

• connectionCreated: wird ausgelöst, wenn ein Client eine Verbindung zu einer Sitzung herstellt

• connectionDestroyed: wird ausgelöst, wenn ein Client die Verbindung zu einer Sitzung trennt

• streamCreatedAbgefeuert, wenn ein Client einen Stream in einer Sitzung veröffentlicht

• streamDestroyedAbgefeuert, wenn ein Client einen Stream aus einer Sitzung herauslöst

Jedes Ereignis hat eine Nutzlast. Analysieren wir das connectionCreated Ereignis als Beispiel:

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

Die Ereignis-Nutzlast enthält Daten, die zur Erstellung der von der Plattform benötigten Geschäftslogik verwendet werden können. Zum Beispiel können wir die connectionId und timestamp verwenden, um die Verbindungszeit eines bestimmten Benutzers zu berechnen. In den nächsten Abschnitten werden wir uns mit detaillierteren Beispielen befassen.

Begrenzung der Verbindungszeit von Benutzern in einer Sitzung

Nehmen wir an, wir haben eine Bildungswebsite, auf der Schüler für eine Stunde Unterricht mit einem Lehrer bezahlen. Nach Ablauf der Stunde muss die Verbindung des Nutzers zur Sitzung unterbrochen werden. Wie können wir dies mit Hilfe der Sitzungsüberwachung umsetzen?

Für diesen Anwendungsfall müssen wir auf die connectionCreated und connectionDestroyed Ereignisse hören. Die Logik wird die folgende sein:

• Starten Sie den Sitzungs-Timer nur, wenn die Verbindungen größer oder gleich zwei sind

• Prüfen Sie alle 5 Sekunden die verstrichene Zeit

• Wenn die Zeit abgelaufen ist, wird die Verbindung zu den Benutzern zwangsweise getrennt.

Schauen wir uns den Code an:

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");
})

Begrenzen Sie die Größe einer Sitzung

Nehmen wir an, wir wollen die Größe einer Sitzung begrenzen, zum Beispiel auf eine Eins-zu-Eins-Verbindung. Wenn jemand anderes eine Verbindung herstellt, wird der Code ihn rausschmeißen. Schauen wir uns den Code an:

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);
 }

In diesem Fall verfolgt der Code, wie viele Verbindungen innerhalb einer Sitzung bestehen. Wenn die Anzahl der Verbindungen größer als 2 ist, wird die Verbindung des Benutzers, der versucht hat, eine Verbindung herzustellen, getrennt. Nach diesem Ansatz könnte die dritte Verbindung einige Sekunden lang eine Verbindung herstellen, und sobald der Server den connectionCreated Hook erhält, wird der Benutzer rausgeschmissen. Es ist möglich, dieses Verhalten zu verbessern, indem man den dritten Benutzer gar nicht erst eine Verbindung zur Sitzung herstellen lässt. Wenn der dritte Benutzer die Anmeldeinformationen anfordert, um der Sitzung beizutreten, kann der Server die Anzahl der Verbindungen in der Sitzung überprüfen. Wenn es bereits zwei Verbindungen gibt, sendet der Server die Anmeldeinformationen nicht an den dritten Benutzer und zeigt eine Fehlermeldung an:

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);
    }
});

Zusätzliche Anwendungsfälle

Wir haben die beiden Hauptanwendungsfälle für die Sitzungsüberwachung gesehen, aber es gibt noch viele weitere, wie z. B. die Möglichkeit, nur autorisierten Benutzern die Teilnahme an der Sitzung zu gestatten oder die Art des Streams zu beschränken, den ein Benutzer veröffentlichen kann.

Erlauben Sie nur autorisierten Benutzern die Teilnahme an der Sitzung

Bei den vertikalen Online-Veranstaltungen ist es wichtig, dass nur autorisierte Benutzer an den Veranstaltungen teilnehmen können. Zum Beispiel können nur Ticketinhaber an einer bestimmten Konferenz teilnehmen. Wir haben eine Liste von Nutzern, die für die Veranstaltung bezahlt haben und teilnehmen dürfen. Wie können Sie diese Daten mit Session Monitoring interpolieren?

Wenn Sie ein Token zum Beitritt zu einer Sitzung erstellen, können Sie Metadaten. Die Metadaten werden im Webhook für Verbindungsereignisse verfügbar sein. Wenn Sie das connectionCreated Ereignis erhalten, können Sie überprüfen, wer die Verbindung ist, und die Daten mit den zugelassenen Benutzern in der Datenbank verifizieren. Wenn der Benutzer nicht berechtigt ist, an der Sitzung teilzunehmen, wird der Server die Verbindung zwangsweise trennen.

Erlauben Sie nur bestimmten Streams die Veröffentlichung der Bildschirmfreigabe

Bisher haben wir nur gesehen, wie die Ereignisse "Verbindung erstellt" und "Verbindung zerstört" verwendet werden, also lassen Sie uns ein Beispiel dafür geben, wie das Ereignis "Stream erstellt" oder "Stream zerstört" genutzt werden kann. Streams-Ereignisse haben zusätzliche Daten wie name und videoType des Streams. Mit letzteren können wir einen Anwendungsfall implementieren, bei dem nur zugelassene Benutzer ihre Bildschirme freigeben können. Denken Sie an ein Finanzberatungsunternehmen, bei dem nur der Finanzberater den Bildschirm freigeben kann, nicht aber der Kunde (um die Weitergabe sensibler Informationen zu vermeiden). Wenn der Server das Ereignis streamCreated Ereignis erhält, kann er prüfen, ob videoType ein Bildschirm ist und ob der Benutzer den Bildschirm freigeben darf. Wenn nicht, kann er den Stream aus der Sitzung herausnehmen.

Wie registriert man die Webhooks?

Sitzungsereignisse und Informationen zur Aktualisierung des Archivstatus können an HTTP-Endpunkten auf Ihrem Server registriert werden. Immer wenn eine registrierte Aktivität auftritt, wird eine HTTP-Anfrage von der OpenTok-Infrastruktur an Ihren Endpunkt gesendet.

Um einen Rückruf zu registrieren:

1. Besuchen Sie Ihre Vonage Video API Account-Seite

2. Wählen Sie das OpenTok-Projekt, für das Sie einen Rückruf registrieren möchten

3. Legen Sie die Callback-URL im Abschnitt Sitzungsüberwachung fest

Wichtig ist, dass wir die Weiterleitung von Ereignissen zur Sitzungsüberwachung deaktivieren, wenn innerhalb von 30 Minuten mehr als 50 Ereignisübermittlungsfehler auftreten (d. h. wenn wir beim Senden einer HTTP-Anfrage an Ihre Rückruf-URL keine 200-Erfolgsantwort erhalten). In diesem Fall senden wir eine E-Mail

Musterantrag

Die Video API Sitzungsüberwachung Beispielanwendung zeigt zwei der oben genannten Beispiele:

1. Begrenzen Sie die Verbindungszeit von Benutzern in einer Sitzung auf der Seite locahost:5000/room/limited-time-room, startet der Server einen Timer, wenn mindestens 2 Verbindungen (2 Benutzer) bestehen. Der Timer prüft alle 5 Sekunden die verbleibende Zeit für die Sitzung. Wenn die Zeit abgelaufen ist, trennt der Server die Benutzer zwangsweise von der Sitzung, indem er den Befehl forceDisconnect Funktion

2. Begrenzen Sie die Größe einer Sitzung: Auf der Seite locahost:5000/room/one-to-onelässt der Server nur zwei Benutzer (Verbindungen) zu, die mit dem Raum verbunden sind. Wenn es eine dritte Verbindung gibt, trennt der Server diese sofort

Schlussfolgerung

Die Sitzungsüberwachung ist ein Schweizer Messer, mit dem Sie Ihrer Video-Anwendung Sicherheit verleihen und serverseitige Prüfungen implementieren können. Um einige der in diesem Blogbeitrag beschriebenen Beispiele in Aktion zu sehen, werfen Sie einen Blick auf das Github Repo: https://github.com/nexmo-se/video-api-session-monitoring. Dieser Blogbeitrag zeigt einige Anwendungsfälle, die mit den Webhooks zur Sitzungsüberwachung implementiert wurden. Die Daten über Verbindungen und Streams auf der Serverseite zu haben, gibt den Entwicklern die Flexibilität, Ereignisse in Echtzeit zu überwachen, zu speichern und darauf zu reagieren.

Wenn Sie diese Funktion ausprobiert haben und Fragen dazu haben, kommen Sie zu unserer Vonage Community Slack oder senden Sie uns eine Nachricht auf Twitter.