Autorización por mensaje y por canal

En una aplicación web clásica nadie discute que cada ruta comprueba si quien llama puede hacer eso sobre ese recurso. En un canal persistente es fácil olvidarlo, porque el código de mensajes vive en otro archivo, a veces en otro servicio, y empieza con una conexión que ya pasó por el inicio de sesión. Pero un mensaje del tipo «únete al canal de la mudanza 40862» es exactamente lo mismo que pedir esa mudanza por su identificador: si nadie comprueba la relación entre la cuenta y el recurso, es una referencia directa insegura con otro transporte.

Hay dos puntos de control. Al suscribirse a un canal, que decide qué podrá escuchar la conexión. Y en cada mensaje que pide una acción, que decide qué podrá cambiar. Los dos se resuelven con datos que tiene el servidor —la identidad que asoció a la conexión y sus propias tablas—, nunca con lo que el mensaje dice de sí mismo.

Abre el laboratorio. En canales.js la suscripción solo comprueba una cosa. Cruza cada mensaje de suscripción de registro-mensajes.txt con mudanzas-por-cuenta.txt.

Ahora la acción de reprogramar. Fíjate en qué dato usa el código para decidir si puede cambiarse la franja, y de dónde sale ese dato. Compáralo con cómo se decide la cancelación unas líneas más abajo, que sí está bien resuelta.

Mide el alcance en el registro. Cuenta solo las reprogramaciones que se aplicaron y que envió una cuenta cuyo rol, en la tabla del servidor, es de cliente. Los intentos ignorados no cuentan, y las de la cuenta de coordinación son legítimas.

La cancelación del mismo archivo muestra el patrón correcto: busca el recurso en el servidor y lo compara con la cuenta asociada a la conexión. Falta extenderlo a todo lo demás y no perder de vista que el canal dura horas: si un coordinador deja de serlo a media jornada, su conexión no debería seguir teniendo el permiso.