
Compartir:
Enrico es un antiguo miembro del equipo de Vonage. Trabajó como ingeniero de soluciones, ayudando al equipo de ventas con su experiencia técnica. Es un apasionado de la nube, las startups y las nuevas tecnologías. Es cofundador de una startup WebRTC en Italia. Fuera del trabajo, le gusta viajar y probar tantas comidas raras como sea posible.
Seguimiento de las conexiones de los usuarios mediante Video API y monitorización de sesiones
Tiempo de lectura: 6 minutos
Introducción
En los últimos años, hemos asistido a un increíble aumento de las plataformas de eventos en línea en las que un usuario compra una entrada y se une a un evento, concierto o clase particular con un profesor desde su navegador. Estas plataformas tienen que garantizar que sólo los usuarios autorizados puedan participar en el evento o la clase, y necesitan un control preciso del tiempo en que los usuarios están conectados a una sesión específica. La mejor manera de poner esto en práctica es disponer de un mecanismo que notifique al servidor de aplicaciones las conexiones y flujos publicados en una sesión en forma de webhook en tiempo real.
Monitoreo de sesión ofrece una manera confiable y segura de monitorear las conexiones en una aplicación de Video API de Vonage. Agregar el monitoreo de sesiones proporciona una capa adicional de seguridad para que los desarrolladores monitoreen la actividad del cliente desde el lado del servidor, verifiquen cada conexión a una sesión de video y registren cada acción por razones de cumplimiento.
Concepts principals
Usando los webhooks de Monitorización de Sesión, los desarrolladores pueden recibir callbacks de eventos de sesión en tiempo real y monitorizar la actividad de su sesión desde el servidor de su aplicación. La infraestructura de OpenTok puede enviar solicitudes HTTP para todas las conexiones realizadas (y destruidas) y flujos creados (y destruidos).
Desglosemos los eventos disponibles:
connectionCreated: se dispara cuando un cliente se conecta a una sesiónconnectionDestroyed: se dispara cuando un cliente se desconecta de una sesiónstreamCreated: se dispara cuando un cliente publica un flujo en una sesiónstreamDestroyed: se dispara cuando un cliente despublica un flujo de una sesión
Cada evento tiene una carga útil. Analicemos el connectionCreated como ejemplo:
{
"sessionId": "2_MX4xMzExMjU3MX5-MTQ3MDI1NzY3OTkxOH45QXRr",
"projectId": "123456",
"event": "connectionCreated",
"timestamp": 1470257688309,
"connection": {
"id": "c053fcc8-c681-41d5-8ec2-7a9e1434a21e",
"createdAt": 1470257688143,
"data": "TOKENDATA"
}
}La carga útil del evento contiene datos que pueden utilizarse para crear la lógica de negocio que necesita la plataforma. Por ejemplo, podemos utilizar las etiquetas connectionId y timestamp para calcular el tiempo de conexión de un usuario específico. En las próximas secciones, profundizaremos en ejemplos más detallados.
Limitar el tiempo de conexión de los usuarios en una sesión
Supongamos que tenemos un sitio web educativo en el que los alumnos pagan por clases de una hora con un profesor. Una vez transcurrida la hora, es necesario desconectar al usuario de la sesión. ¿Cómo podemos implementar esto utilizando Session Monitoring?
Para este caso de uso, tenemos que escuchar las señales connectionCreated y connectionDestroyed . La lógica va a ser la siguiente:
Iniciar el temporizador de sesión sólo si las conexiones son mayores o iguales a dos
Comprueba cada 5 segundos el tiempo transcurrido
Una vez transcurrido el tiempo, desconectar forzosamente a los usuarios.
Veamos el código:
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");
})
Limitar el tamaño de una sesión
Supongamos que queremos limitar el tamaño de una sesión, por ejemplo a una de uno a uno. Si alguien más se conecta, el código lo expulsará. Veamos el código:
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);
}
En este caso, el código está rastreando cuántas conexiones hay dentro de una sesión. Si el número de conexiones es superior a 2, va a desconectar al usuario que ha intentado conectarse. Siguiendo este enfoque, la tercera conexión sería capaz de conectarse durante unos segundos y una vez que el servidor recibe el connectionCreated hook, el usuario será expulsado. Es posible mejorar este comportamiento no permitiendo siquiera que el tercer usuario se conecte a la sesión. Cuando el tercer usuario solicita las credenciales para unirse, el servidor puede comprobar el número de conexiones en la sesión. Si ya hay dos conexiones, el servidor no enviará las credenciales al tercer usuario y mostrará un mensaje de error:
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);
}
});
Casos de uso adicionales
Hemos visto los dos principales casos de uso de la supervisión de sesiones, pero hay muchos más, como permitir que sólo los usuarios autorizados se unan a la sesión o limitar el tipo de flujo que un usuario puede publicar.
Permitir que sólo los usuarios autorizados se unan a la sesión
En la vertical de eventos en línea es importante permitir que sólo los usuarios autorizados se unan a los eventos. Por ejemplo, sólo los titulares de entradas pueden asistir a una conferencia específica. Tenemos una lista de usuarios que han pagado por el evento y están autorizados a unirse, ¿cómo se pueden interpolar estos datos con Session Monitoring?
Cuando se crea un token para unirse a una sesión, se pueden añadir metadatos. Los metadatos estarán disponibles en el webhook de eventos de conexión. Cuando reciba el evento connectionCreated puede comprobar quién es la conexión y verificar los datos con los usuarios permitidos en la base de datos. Si el usuario no está autorizado a unirse a la sesión, el servidor forzará su desconexión.
Permitir que sólo determinados flujos publiquen pantalla compartida
Hasta ahora sólo hemos visto cómo utilizar los eventos de conexión creada y destruida, así que vamos a hacer un ejemplo de cómo aprovechar el evento de stream creado o destruido. Los eventos de flujo tienen datos adicionales como name y videoType del stream. Usando este último, podemos implementar un caso de uso donde sólo los usuarios permitidos pueden compartir sus pantallas. Pensemos en una empresa de consultoría financiera, donde queremos que sólo el asesor financiero pueda compartir la pantalla y no el cliente (evitar compartir información sensible). Cuando el servidor recibe el evento streamCreated puede comprobar si videoType es pantalla y si el usuario tiene permiso para compartir la pantalla. Si no, puede despublicar el stream de la sesión.
¿Cómo registrar los webhooks?
Los eventos de sesión y la información de actualización del estado del archivo pueden registrarse en puntos finales HTTP dentro de su servidor. Cada vez que se produce una actividad registrada, se emite una solicitud HTTP desde la infraestructura de OpenTok a su punto final.
Para registrar una devolución de llamada:
Visita la página de tu cuenta de Video API de Vonage
Selecciona el proyecto OpenTok para el que deseas registrar una devolución de llamada
Establezca la URL de devolución de llamada en la sección Supervisión de la sesión
Una cosa muy importante a tener en cuenta es que si en 30 minutos hay más de 50 fallos de entrega de eventos (en los que no recibimos una respuesta 200 de éxito al enviar una petición HTTP a su URL de devolución de llamada), desactivaremos el reenvío de eventos de monitorización de sesión. Enviaremos un correo electrónico si esto ocurre
Ejemplo de solicitud
En Monitorización de sesiones de la Video API muestra dos de los ejemplos mencionados anteriormente:
Limitar el tiempo de conexión de los usuarios en una sesión en la página locahost:5000/room/limited-time-room, el servidor iniciará un temporizador cuando haya al menos 2 conexiones (2 usuarios). El temporizador comprobará cada 5 segundos el tiempo restante de la sesión. Cuando el tiempo haya expirado, el servidor forzará la desconexión de los usuarios de la sesión usando el comando forceDisconnect en
Limitar el tamaño de una sesión: en la página
locahost:5000/room/one-to-oneel servidor sólo permitirá dos usuarios (conexiones) conectados a la sala. Si hay una tercera conexión, el servidor la desconectará inmediatamente.
Conclusión
La monitorización de sesiones es una navaja suiza para añadir seguridad e implementar comprobaciones del lado del servidor a tu aplicación de vídeo. Para ver algunos de los ejemplos descritos en esta entrada del blog en acción echa un vistazo a la repo Github: https://github.com/nexmo-se/video-api-session-monitoring. Esta entrada de blog muestra un par de casos de uso implementados con los webhooks de monitorización de sesión. Disponer de los datos sobre conexiones y flujos en el lado del servidor ofrece a los desarrolladores la flexibilidad necesaria para monitorizar, almacenar y reaccionar ante eventos en tiempo real.
Si has probado esta función y tienes preguntas al respecto, únete a nuestra Slack de la comunidad de Vonage o envíanos un mensaje en Twitter.
Compartir:
Enrico es un antiguo miembro del equipo de Vonage. Trabajó como ingeniero de soluciones, ayudando al equipo de ventas con su experiencia técnica. Es un apasionado de la nube, las startups y las nuevas tecnologías. Es cofundador de una startup WebRTC en Italia. Fuera del trabajo, le gusta viajar y probar tantas comidas raras como sea posible.