asp.net - tiempo - signalr q es

La sesión de Asp.net nunca caduca cuando se usa SignalR y el modo de transporte sondeo largo

Question

Tenemos una aplicación web que utiliza SignalR para su mecanismo de notificación. El problema es que cuando navegamos en nuestra aplicación web utilizando IE, SignalR usa Sondeo Largo ya que su tipo de transporte envía solicitudes a nuestro servidor web, por lo que la sesión nunca caduca, no importa cuánto el navegador está inactivo

Pensamos que tal vez podríamos captar las solicitudes en Global.asax y ver si eran de SingalR y establecer el tiempo de espera de la sesión en el tiempo restante (lo cual no creo que sea una solución sencilla).

¿Hay alguna otra solución que nos falte?

Answer 1

Aquí publico la solución comentada de @Simon Mourier, con su aprobación , como respuesta de CW, ya que encuentro que el enfoque sugerido es el más apropiado y menos intrusivo, ya que simplemente deshabilita la sesión para las solicitudes de SignalR.

Un efecto secundario positivo es que la solicitud se procesará más rápido, ya que no es necesario iniciar y cargar el objeto Session.

Todavía usa un IHttpModule para el trabajo, y el lugar preferible es probablemente el evento AcquireRequestState (aún no probado personalmente), o en un evento mencionado anteriormente, antes de utilizar el objeto Session.

Tenga en cuenta, utilizando este enfoque, que podría ser necesario probar que el objeto Session está disponible antes de acceder a cualquiera de sus miembros u objetos almacenados.

public class SignalRSessionBypassModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.AcquireRequestState += OnAcquireRequestState;
}
private bool IsSignalrRequest(string path)
{
return path.IndexOf("/signalr/", StringComparison.OrdinalIgnoreCase) > -1;
}
protected void AcquireRequestState(object sender, EventArgs e)
{
var httpContext = ((HttpApplication)sender).Context;
if (IsSignalrRequest(httpContext.Request.Path))
{
// Run request with Session disabled
httpContext.SetSessionStateBehavior(System.Web.SessionState.SessionStateBehavior.Disabled);
}
}
public void Dispose()
{
}
}

Aquí hay otro enfoque completamente diferente, simple, pero bastante eficiente.

En lugar de confiar en las cookies de sesión / autenticación para decidir si un usuario ha agotado el tiempo de espera, use el objeto Caché. Esto tiene más o menos efectos secundarios y funciona como si el usuario simplemente se desconectara.

Simplemente agregue este pequeño fragmento en algún lugar al principio del código de su aplicación web, donde, por supuesto, SignalR no funciona, podrá verificar si el elemento de caché está allí y reiniciarlo (con el mismo tiempo de caducidad que el tiempo de espera de la sesión está configurado), y si no, simplemente cierre la sesión y elimine las cookies / variables de sesión.

if (Request.IsAuthenticated) {
if (Cache[Context.User.Identity.Name] == null) {
// Call you logout method here...,
// or just:
// - Sign out from auth;
// - Delete auth cookie
// - Remove all session vars
} else {
// Reinitiate the cache item
Cache.Insert(Context.User.Identity.Name,
"a to you usable value",
null,
DateTime.Now.AddMinutes(Session.Timeout),
Cache.NoSlidingExpiration,
CacheItemPriority.Default,
null
);
}

Y dentro de su método de inicio de sesión de usuario, simplemente agregue esto, para crear el elemento de caché por primera vez

// Insert the cache item
Cache.Insert(Context.User.Identity.Name,
"a to you usable value",
null,
DateTime.Now.AddMinutes(Session.Timeout),
Cache.NoSlidingExpiration,
CacheItemPriority.Default,
null
);

Answer 2

Es más estable y mantenible, en mi opinión, tener tu propia "sesión como tiempo de espera". Establezca el tiempo de espera de la sesión de .NET en infinito ya que no lo usará y luego creará un contador global de JavaScript (en su diseño o página maestra) para rastrear el paso del tiempo mientras el navegador está inactivo (obviamente setTimeout o setInterval cada pocos segundos) Haz el truco). Asegúrate de que el contador se reinicie en cada solicitud web (esto debería suceder automáticamente ya que todas las variables de JavaScript se reiniciarían). En caso de que tenga páginas que dependan de servicios web o API web, asegúrese de restablecer su contador global de JavaScript en cada llamada. Si el contador alcanza el tiempo de espera deseado sin restablecerse, eso significa que la sesión ha caducado y puede cerrar la sesión del usuario. Con este enfoque, tendrá control total sobre el tiempo de vida de la sesión, lo que le permite crear una ventana emergente de temporizador de cierre de sesión para advertir al usuario que la sesión está a punto de caducar. SignalR encajaría perfectamente con este enfoque ya que el temporizador de JavaScript seguiría funcionando.

Answer 3

La solución que estoy usando actualmente es un IHttpModule para verificar si la solicitud es una solicitud de Signalr; si es así, elimine la cookie de autenticación, esto evitará que el tiempo de espera de la sesión de ASP.net se reinicie, por lo que si el Tiempo de espera de la sesión es de 20 minutos y las únicas solicitudes En Signalr, la sesión del usuario aún se agotará y el usuario tendrá que iniciar sesión nuevamente.

 public class SignalRCookieBypassModule : IHttpModule
{
public void Init(HttpApplication application)
{
application.PreSendRequestHeaders += OnPreSendRequestHeaders;
}
private bool IsSignalrRequest(string path)
{
return path.IndexOf("/signalr/", StringComparison.OrdinalIgnoreCase) > -1;
}
protected void OnPreSendRequestHeaders(object sender, EventArgs e)
{
var httpContext = ((HttpApplication)sender).Context;
if (IsSignalrRequest(httpContext.Request.Path))
{
// Remove auth cooke to avoid sliding expiration renew
httpContext.Response.Cookies.Remove(DefaultAuthenticationTypes.ApplicationCookie);
}
}
public void Dispose()
{
}
}

Creo que esta es una verdadera solución de pirateo, por lo que me encantarían otras ideas para evitar que se agote el tiempo de espera de la sesión cuando los datos se envían al cliente desde el servidor, o cuando el cliente de javascript sondea un punto final para obtener datos.

Answer 4

Si echas un vistazo a la descripción del protocolo SignalR que escribí hace un tiempo, encontrarás esto:

»Haga ping al servidor ... Observaciones: la solicitud de ping no es realmente una" solicitud de administración de conexión ". El único propósito de esta solicitud es mantener viva la sesión ASP.NET . Solo es enviado por el cliente JavaScript.

Entonces, supongo que la solicitud de ping está haciendo su trabajo.