asp.net - how - install asp net windows server 2012 r2
Asp.net Sesiones que se cruzan/mezclan (7)
Si comprobó que el almacenamiento en caché de salida no es el problema
Ya hay una respuesta de mi parte aquí, pero como resultó que mi otra solución (deshabilitar el caché de salida) realmente no resolvió nuestro problema por nosotros.
Como en la pregunta se afirma que el almacenamiento en caché está desactivado, el único otro posible error (AFAIK) que puede producir esto es lo que resultó ser el verdadero culpable en nuestro caso: usamos una variable privada en un ActionFilterAttribute .
Y debido a que estos se almacenan en caché, el almacenamiento de datos privados / personales de un usuario de esta manera también puede llevar a una mezcla de sesiones.
Esta respuesta describe cuál fue nuestro problema y cómo solucionarlo:
https://stackoverflow.com/a/8937793/1864395
Además, creo que es bueno mencionar que pudimos reproducir el problema ejecutando Apache JMeter con un escenario para varios usuarios al mismo tiempo. Es una herramienta realmente agradable (aunque no es realmente fácil de usar / intuitiva) utilizada para (entre otras cosas) pruebas de estrés. ¡Es probablemente la única forma de diagnosticar mezclas de sesiones!
Hace unas semanas, uno de nuestros clientes nos contactó y nos dijo que a veces, cuando crea una actividad, ¡se crea bajo el nombre de otra persona!
Hicimos algunos problemas y no pudimos encontrar nada. Le pedimos al usuario que nos contactara la próxima vez que experimentara estos problemas. Él se puso en contacto con nosotros y pudimos hacer algo con él y ver el problema con nuestros propios ojos.
No fueron solo las actividades, fue reconocido como alguien más en la aplicación. Tenía acceso a todo lo que la otra persona debería tener acceso. Fue entonces cuando nos dimos cuenta de que estamos teniendo un problema de sesión mixta.
Un poco sobre nuestro código:
Al igual que cualquier otra aplicación, tenemos una página de inicio de sesión simple en la que el usuario ingresa el correo electrónico y la contraseña, los autenticamos en nuestra base de datos y, si son válidos, llamamos a FormsAuthentication.SetAuthCookie () para guardar la identificación de usuario actual en la cookie y le permitimos ingresar.
BL.User currentUser = BL.User.Authenticate(txtUsername.Text, txtPassword.Text);
if (currentUser != null)
{
this.Session["NumberOfLoginTried"] = "0";
FormsAuthentication.SetAuthCookie(currentUser.UserID.ToString(), chRememberMe.Checked);
Response.Redirect(FormsAuthentication.GetRedirectUrl(currentUser.UserID.ToString(), false));
}
También utilizamos el siguiente fragmento de código para obtener la identificación de usuario registrado (usuario actual) en nuestra aplicación.
public static int GetCurrentUserID()
{
int userID = -1;
int.TryParse(HttpContext.Current.User.Identity.Name, out userID);
return userID;
}
Y sí, hicimos nuestra tarea y buscamos en Google y hemos visto los siguientes dos enlaces:
http://lionsden.co.il/codeden/?p=446
Mezcla de sesiones de ASP.NET utilizando StateServer (¡SCARY!)
Hemos deshabilitado el almacenamiento en caché en modo kernel y el almacenamiento en modo usuario para archivos .aspx y .ascx y esto sigue ocurriendo.
PS: la aplicación se ejecuta en Windows 2008 R2 con IIS 7.5. Y NO estamos usando sesión sin cookies.
Acabamos de tener un problema muy similar, que ocurrió al azar, aparentemente no reproducible.
El problema resultó ser el mecanismo de almacenamiento en caché de la página ASP.NET: en nuestro caso, la etiqueta <%@ OutputCache en particular.
Había una línea que habíamos usado <%@ OutputCache NoStore="true" Duration="1" %> que básicamente significaba que si dos usuarios accedían a la misma página dentro de 1 segundo uno del otro verían la misma página (incluida la sesión iniciada nombre de usuario del otro usuario). Así que si actualizaron dicha página, obtuvieron la información correcta.
En nuestro caso, cambiando dicha línea a <%@ OutputCache NoStore="true" Duration="1" VaryByParam="*" %> , deshabilitando el almacenamiento en caché del kernel en IIS como en este enlace ( http://lionsden.co.il/codeden/?p=446 )
y agregando las siguientes líneas al evento Page_Load de la página en cuestión:
Response.CacheControl = "private";
Response.ExpiresAbsolute = DateTime.Now.AddDays(-1d);
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Parece haber resuelto el problema por nosotros. Esperemos que esto ayude a alguien más con un problema similar.
Como todos ustedes deshabilitaron el almacenamiento en caché en modo kernel, me gustaría señalar algunas otras ideas.
1) Para usar correctamente HttpContext.Current.User.Identity.Name , primero debe verificar que su usuario haya iniciado sesión utilizando User.Identity.IsAuthenticated
2) en este punto Session.Add("CurrentUser", currentUser); ¿Qué es lo que realmente intentas ahorrar?
Ahora creo que ese es el problema en caché. Las páginas se almacenan en algún lugar entre sus usuarios y la una se mezcla con la otra. Algunos de los encabezados que puede usar para su página para evitar el caché en las computadoras proxy del medio.
Response.Cache.SetExpires(DateTime.UtcNow.AddYears(-2));
Response.Cache.SetNoStore();
Response.Cache.SetValidUntilExpires(false);
Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.ExpiresAbsolute = DateTime.Now.Subtract(new TimeSpan(1, 0, 0, 0));
Response.Expires = 0;
Response.CacheControl = "no-cache";
Response.AppendHeader("Pragma", "no-cache");
También digo que si sus páginas tienen datos que no desea compartir entre su usuario, necesita usar páginas HTTPS seguras, y configure sus cookies para que estén disponibles solo en páginas seguras agregando <httpCookies httpOnlyCookies="true" requireSSL="true" /> en web.config
Además, verifique si guarda su sesión en el servidor SQL que programó para ejecutar el enrutamiento de limpieza cada 1 minuto.
Para poder encontrar más información, sugiero que almacene un poco de texto oculto en las páginas, por ejemplo, la fecha y la hora del renderizado, tal vez el último 4 dígitos del ID de usuario, y otras cosas que puede ayudarlo a ver si La página viene de un caché o no.
Dado que esto parece caer en el territorio del problema extremadamente arcano, tal vez es hora de un salto.
Podría dejar de usar la sesión ASP.NET para almacenar sus identificadores por completo.
Usted tiene un montón de opciones de donde podría pegar esta información en su lugar. Puede elegir cifrarlo en la propiedad UserData del ticket de autenticación de formularios (lo he hecho antes en la producción, funciona muy bien para almacenar una (s) clave (s), csv de roles o incluso pequeños objetos json). Más allá de los formularios de la solicitud, puede escribir la información directamente como su propia cookie. También podría pasar por alto las cookies por completo.
Si elige omitir las cookies, básicamente está ingresando a un territorio similar de las sesiones ASP.NET sin cookies. Tiene un par de opciones, podría hacer que el identificador de usuario esté separado de cada URL como parámetro de consulta. Otra opción sería crear un HttpModule que agregaría una entrada de formulario oculta en cada respuesta de página que contenga el identificador del usuario registrado.
Si recorres la ruta sin cookies, asegúrate de que no sea posible usar tu sitio como HTTP y que cada solicitud sea HTTPS. Incluso más especialmente si utiliza el método de parámetro de consulta.
Tuvimos el mismo problema en la empresa en la que trabajo. También nos dimos cuenta de que fue causado por el almacenamiento en caché de salida, lo que resultó en enviar el SessionId de otra persona a la persona incorrecta.
Ahora hemos agregado el siguiente elemento <caching> a nuestro web.config.
<configuration>
[...]
<system.webServer>
[...]
<caching enabled="false" enableKernelCache="false">
</caching>
</system.webServer>
[..]
</configuration>
No podemos garantizar que esto lo resolverá, porque el problema es casi imposible de reproducir, pero según nuestra investigación, esto debería resolverlo.
Curiosamente, el enlace a un artículo de Microsoft que describe este problema que se puede encontrar en Internet ofrece una página general como si la página hubiera sido eliminada.
Pero hay un artículo de Microsoft que parece describir el mismo problema para IIS 6:
Lo que describe el síntoma como:
Considere el siguiente escenario. Una página de Microsoft ASP.NET contiene la directiva <% @ OutputCache%>. Además, la página ASP.NET genera un encabezado HTTP que contiene una respuesta Set-Cookie. En este escenario, la página ASP.NET se almacena en el caché de kernel de la pila del protocolo HTTP (HTTP.sys) en Microsoft Internet Information Services (IIS) 6.0. Por lo tanto, varios usuarios que acceden a la misma página pueden recibir cookies idénticas.
Actualizar
Encontré este artículo realmente bueno en el blog Microsoft Premier Developer que explica mucho:
Intercambio de sesiones de ASP.Net: ¿por qué sucede y qué se puede hacer al respecto?
Tuvimos el mismo problema y fue causado por la <clientCache/> en IIS, que de manera predeterminada no agrega el encabezado HTTP Cache-Control: private . ¡La falta de este encabezado significaba que nuestras cookies de autenticación de formularios estaban siendo almacenadas en caché por servidores proxy descendentes! Entonces, cuando nuestro sitio se llenó, de repente, ¡una carga de usuarios se registra de repente como el usuario equivocado! Pesadilla.
si se elimina el <%@ OutputCache NoStore="true" Duration="1" VaryByParam="*" (¡en todos los archivos ascx que están en la línea de Master a aspx también!) impidieron las sesiones cruzadas. habiendo cargado solo una directiva ascx con outputcache, ocurrieron sesiones cruzadas.
No importaba en mi caso si usaba sessionstat InProc o StateServer, si tenía sesiones sin cookies o con cookies.