SignalR: cómo forzar la autenticación/terminar las conexiones del concentrador del lado del servidor

Question

Esta pregunta está relacionada con otro hilo, puede leer here: Forms authentication with SignalR donde intenté con la ayuda y la paciencia del usuario dfowler para comprender cómo aplicar formularios Autenticación de formularios ASP .NET un concentrador SignalR.

Descripción del problema: Deseo que solo los usuarios autenticados puedan conectar SignalR Hub y recibir/enviar mensajes.

Escenario de intrusión: el intruso puede potencialmente capturar/acceder al HTML y JavaScript de la página web que accede a los archivos temporales en una computadora cliente. Por lo tanto, este intruso puede conocer todos los detalles (métodos, nombres de hub, etc.) necesarios para configurar/usar una conexión al Hub. Una propuesta de solución de dfowler es implementing IConnect:

implementarías IConnected y escribir el siguiente código en Conectar si (Context.User.Identity.IsAuthenticated!) Throw new Excepción ("GTFO");

Por lo tanto he intentado con algo como esto

public System.Threading.Tasks.Task Connect() 
    { 
     if (!Context.User.Identity.IsAuthenticated 
      || !(Context.User.IsInRole("role1") || Context.User.IsInRole("role2") 
      )) 
      throw new Exception("User not authorized"); 
     return null; 
    } 

El problema, una vez probado, es que cuando se está llamando el método Connect, la conexión se ha establecido ya y sencillo que lanza la excepción no ayudará (Si lo recibí si de hecho se usa Connect, se debe usar para enviar un mensaje al cliente en la conexión, lanzar una excepción solo arrojará en un mensaje de bienvenida no enviado).

De hecho, según mis pruebas, los clientes todavía pueden leer todos los mensajes (y también enviarlos).

Ahora, enfoques que vienen a la mente:

1. La solución perfecta: rechazar o terminar la conexión en el lado del servidor: ni idea de cómo hacer esto en SignalR (He intentado encontrar un método en el API pero sin suerte)
2. comprobar si el usuario es parte de un grupo para evitar recibir/enviar mensajes a él (pero esto sigue siendo propenso a/ataques de inundación DOS)
3. envío de un mensaje al cliente para desconectar: ​​obviamente, no ayuda en caso de que esté luchando contra un intruso.

¿Algún otro enfoque? Cualquier forma de terminar la conexión en el lado del servidor o se debe aceptar que la única autentificación real es la de la página web del host (dejando abierta la puerta a todos los ataques al cliente de señalR?)

EDITAR

Aquí es la secuencia de la comunicación cliente - servidor cuando se utiliza el método IConnect.Connect tirar incondicionalmente una excepción (navegador IE9):

Parece que la foreverFrame falla pero se está estableciendo la opción de reserva de longPolling y funciona de todos modos - esto después de arrojar el error capturado en el Javascript por el bloque

if (connection.state === signalR.connectionState.connecting) { 
      // Connection hasn't been started yet 
      throw "SignalR: Connection has not been fully initialized. 
    Use .start().done() or .start().fail() to run logic after 
    the connection has started."; 
     } 

Answer 1

Tenemos un problema por el que debemos permitir bloquear la conexión por completo. Ahora mismo deberás proteger cada método. No es el más limpio, pero para 1.0 alpha1 tendremos algún mecanismo para hacer esto.

Un problema adicional es que es la misma conexión para todos los concentradores, por lo que no puede rechazar una conexión para un concentrador específico.

EDITAR

En realidad si lo tiras termina la conexión en lo que va mis pruebas. ¿Qué comportamiento estás viendo?