asp.net - dragon - session id facebook

ASP.NET: Session.SessionID cambia entre solicitudes

Question

¿Por qué la propiedad SessionID en la sesión -objeto en una página ASP.NET- cambia entre las solicitudes?

Tengo una página como esta:

...
<div>
SessionID: <%= SessionID %>
</div>
...

Y la salida cambia constantemente cada vez que presiono F5, independientemente del navegador.

Answer 1

Asegúrese de no tener un tiempo de espera de sesión muy corto, y también asegúrese de que si está utilizando sesiones basadas en cookies, está aceptando la sesión.

FireFox webDeveloperToolbar es útil en momentos como este ya que puede ver las cookies establecidas para su aplicación.

Answer 2

El restablecimiento de ID de sesión puede tener muchas causas. Sin embargo, cualquiera de los mencionados anteriormente no se relaciona con mi problema. Así que lo describiré para futuras referencias.

En mi caso, una nueva sesión creada en cada solicitud dio como resultado un bucle infinito de redireccionamiento. La acción de redirección se lleva a cabo en el evento OnActionExecuting .

También he estado borrando todos los encabezados http (también en el evento OnActionExecuting usando el método Response.ClearHeaders ) para evitar el almacenamiento en caché de los sitios en el lado del cliente. Pero ese método borra todos los encabezados, incluida la información sobre la sesión del usuario y, en consecuencia, todos los datos en el almacenamiento Temp (que estaba utilizando más adelante en el programa). Así que incluso establecer una nueva sesión en el evento Session_Start no ayudó.

Para resolver mi problema me aseguré de no eliminar los encabezados cuando ocurre una redirección.

Espero que ayude a alguien.

Answer 3

En mi caso, descubrí que la cookie de sesión tenía un dominio que incluía www. prefijo, mientras estaba solicitando una página sin www. .
Añadiendo www. a la URL corrigió de inmediato el problema. Más tarde cambié el dominio de cookie para establecerlo en .mysite.com lugar de www.mysite.com .

Answer 4

En mi caso, esto estaba sucediendo mucho en mis entornos de desarrollo y prueba. Después de probar todas las soluciones anteriores sin éxito, descubrí que podía solucionar este problema eliminando todas las cookies de sesión. La extensión de desarrollador web hace que esto sea muy fácil de hacer. Uso principalmente Firefox para probar y desarrollar, pero esto también ocurrió mientras probaba en Chrome. La corrección también funcionó en Chrome.

No he tenido que hacer esto todavía en el entorno de producción y no he recibido ningún informe de personas que no puedan iniciar sesión. Esto también parecía suceder después de hacer que las cookies de sesión fueran seguras. Nunca sucedió en el pasado cuando no estaban seguros.

Answer 5

Esta es la razón

Cuando se usa un estado de sesión basado en cookies, ASP.NET no asigna almacenamiento para los datos de la sesión hasta que se utiliza el objeto Session. Como resultado, se genera una nueva ID de sesión para cada solicitud de página hasta que se acceda al objeto de sesión. Si su aplicación requiere una ID de sesión estática para toda la sesión, puede implementar el método Session_Start en el archivo Global.asax de la aplicación y almacenar datos en el objeto Session para arreglar la ID de la sesión, o puede usar el código en otra parte de su aplicación para almacenar datos de manera explícita en el objeto Session.

http://msdn.microsoft.com/en-us/library/system.web.sessionstate.httpsessionstate.sessionid.aspx

Así que, básicamente, a menos que acceda a su objeto de sesión en el backend, se generará una nueva sessionId con cada solicitud

EDITAR

Este código debe agregarse en el archivo Global.asax. Agrega una entrada al objeto Session para que corrija la sesión hasta que caduque.

protected void Session_Start(Object sender, EventArgs e)
{
Session["init"] = 0;
}

Answer 6

Hay otra razón, más insidiosa, por la que esto puede ocurrir incluso cuando el objeto Session se ha inicializado como lo demostró Cladudio.

En Web.config, si hay una entrada <httpCookies> que está configurada para requireSSL="true" pero no está realmente usando HTTPS: para una solicitud específica, entonces la cookie de sesión no se envía (o tal vez no se devuelve, No estoy seguro de qué) lo que significa que terminas con una nueva sesión para cada solicitud.

Encontré este de la manera difícil, pasando varias horas yendo y viniendo entre varias confirmaciones en mi control de fuente, hasta que encontré qué cambio específico había roto mi aplicación.

Answer 7

Me encontré con este problema de otra manera. Los controladores que tenían este atributo [SessionState(SessionStateBehavior.ReadOnly)] estaban leyendo desde una sesión diferente a pesar de que había establecido un valor en la sesión original al inicio de la aplicación. Estaba agregando el valor de la sesión a través de _layout.cshtml (¿quizás no sea la mejor idea?)

Claramente fue el ReadOnly el que causó el problema porque cuando eliminé el atributo, la sesión original (y SessionId) se mantendrían intactas. El uso de la solución de Claudio / Microsoft lo solucionó.

Answer 8

Mi problema era con una aplicación de MediaTV de Microsoft MediaRoom. Resulta que las aplicaciones MPF MRML no son compatibles con las cookies; cambiar para usar sesiones sin cookies en la web.config resolvió mi problema

<sessionState cookieless="true" />

Aquí hay un artículo REALMENTE viejo al respecto: ASP.NET sin cookies

Answer 9

Otra posibilidad que causa que el SessionID cambie entre solicitudes, incluso cuando Session_OnStart está definido y / o se ha inicializado una sesión, es que el nombre de host de URL contiene un carácter no válido (como un guión bajo). Creo que esto es específico de IE (no verificado), pero si su URL es, por ejemplo, http://server_name/app , entonces IE bloqueará todas las cookies y no se podrá acceder a su información de sesión entre las solicitudes.

De hecho, cada solicitud generará una sesión separada en el servidor, de modo que si su página contiene múltiples imágenes, etiquetas de scripts, etc., cada una de esas solicitudes GET generará una sesión diferente en el servidor.

Más información: http://support.microsoft.com/kb/316112

Answer 10

Usando la respuesta de Neville (eliminando requireSSL = true, en web.config) y modificando ligeramente el código de Joel Etherton, este es el código que debe manejar un sitio que se ejecute tanto en modo SSL como en modo no SSL, dependiendo del usuario y la página (I Estoy volviendo al código y aún no lo he probado en SSL, pero espero que funcione, ya que estará demasiado ocupado más tarde para volver a esto, así que aquí está:

if (HttpContext.Current.Response.Cookies.Count > 0)
{
foreach (string s in HttpContext.Current.Response.Cookies.AllKeys)
{
if (s == FormsAuthentication.FormsCookieName || s.ToLower() == "asp.net_sessionid")
{
HttpContext.Current.Response.Cookies[s].Secure = HttpContext.Current.Request.IsSecureConnection;
}
}
}

Answer 11

en mi caso fue porque estaba modificando la sesión después de redireccionar desde una puerta de enlace en una aplicación externa , así que porque estaba usando IP en lugar de localhost en esa url de la página, en realidad se consideraba un sitio web diferente con diferentes sesiones.

En resumen

presta más atención si estás depurando una aplicación alojada en IIS en lugar de IIS express y mezclando tu máquina http: // Ip y http: // localhost en varias páginas

Answer 12

mi problema era que teníamos este conjunto en web.config

<httpCookies httpOnlyCookies="true" requireSSL="true" />

esto significa que al depurar en no SSL (el valor predeterminado), la cookie de autenticación no se enviará de vuelta al servidor. esto significaría que el servidor enviaría una nueva cookie de autenticación (con una nueva sesión) para cada solicitud al cliente.

la solución es establecer requiressl en false en web.config y true en web.release.config o activar SSL durante la depuración: