2009-10-29 32 views
16

Almacenamos dos objetos en sesión. De alguna manera, uno de los objetos de otro usuario se cargó en una sesión de usuario diferente. El usuario no debería haber tenido acceso a estos datos en particular, y tan pronto como lo vieron sabían que algo estaba muy mal.Mezcla de sesiones ASP.NET utilizando StateServer (SCARY!)

Tenemos prueba visual de los datos que se le presentaron, y hay ciertamente de ninguna manera podría haber pasado a menos que las sesiones se mezclaron. Esta es una situación muy aterradora que no podemos descubrir (no podemos reproducirla). La única respuesta para nosotros es echarle la culpa a ASP.NET StateServer por mezclar las variables de la sesión, lo cual es completamente inaceptable y nos pone en una mala posición.

Nuestras aplicaciones son ASP.NET 2.0 que se ejecutan en Windows Server 2003 con IIS6, utilizando el modo de sesión StateServer cookieless="false" y FormsAuthentication.

¿Alguien más ha tenido este problema? ¿Cómo podemos resolverlo?

+0

He visto esto, pero en .Net 1.1. t fue supuestamente arreglado en 2.0. Tengo algunas preguntas antes de intentar publicar una respuesta. Primera pregunta, ¿estás usando una sesión sin cookies? – David

+0

Gracias! Sí, sin cookies (dice en la pregunta). –

+0

Lo siento ... No lo leí. Dado que el uso de sesiones sin cookies significa que el ID de sesión se incluye en la URL como parámetro de cadena de consulta, ¿ha verificado que el parámetro de secuencia de comandos de SessionID de la URL es diferente entre los dos usuarios cuando sucede esto? – David

Respuesta

12

nos encontramos con este problema exacto en mi anterior empresa y tomó 3 semanas para depurarlo. ASP.NET estaba dando a un usuario el estado de sesión de otra persona. Fue realmente imposible de duplicar en un entorno de depuración.

El arreglo cuando lo encontramos era solo algo en web.config. No lo recuerdo completamente, así que pasé un tiempo buscando en Google. Creo que el problema tenía algo que ver con el almacenamiento en caché de resultados. Eche un vistazo a este artículo en "Caché de resultados y sesiones".

http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineJuly2006en-us.chm (el artículo se titula Mantener en buen funcionamiento Sitios evitando estos 10 Común ASP.NET Errores por Jeff Prosise en julio de 2006 edición de la revista MSDN)

Si eso suena como su escenario, entonces el arreglo podría estar deshabilitando la opción enableKernelOutputCache en web.config.

Buena suerte.

+0

¡Creo que tienes razón! De hecho, tuvimos el almacenamiento en caché de resultados habilitado en * un * formulario web, y el formulario fue el responsable de llenar nuestra variable de sesión discrepante. ¡Eres un santo, un erudito, un caballero, un genio, y no puedo agradecerte lo suficiente! –

+0

+1. Aunque Josh dijo que solo se cambió una variable, no toda la sesión, como se indica en su enlace. – wtaniguchi

+0

Para aclarar, solo tengo * prueba * de que se cambió una variable. –

5

Primero busque errores en su propio código: esta es la explicación más probable. P.ej. utilizando campos estáticos u otra memoria compartida, como la memoria caché ASP.NET para datos específicos del usuario.

+0

Acabo de pasar los últimos diez días haciendo esto. Destaqué la palabra "ciertamente" en mi pregunta por una razón. Confía en mí, nuestro código es a prueba de balas. –

+0

Además, esta aplicación ha estado en producción durante años y solo hemos encontrado este problema una vez. –

+0

+1 Cada vez que he visto algo como lo que Josh está describiendo, ese es el culpable. – kemiller2002

0

¿Cuántas veces ocurrió? ¿Revisó si los usuarios usaban el navegador anterior o enviaban enlaces entre sí con los identificadores de sesión?

Una forma de verificar con certeza el error de State Server es cambiar a otro administrador de sesión, recurrir a in-proc si puede o usar SQL Server pero sería mejor encontrar una manera de reproducir el error primero para que podría probarlo.

+0

Solo ha ocurrido una vez. Volver al navegador definitivamente no es así, porque la autenticación de los usuarios no permitiría el acceso a estos datos en ningún momento. No hay manera de que estén haciendo algo como piratear ID de sesión, nuestros usuarios son hombres de negocios mayores que ni siquiera saben qué es una sesión. –

0

¿Podrían los dos usuarios cruzados estar utilizando el mismo proxy de caché? Si es así, un usuario podría ver los datos que se almacenaron en la memoria caché de otro usuario si las URL coinciden, especialmente si el proxy no se comporta bien.

¿Este no era el principal problema con el proyecto Google Web Accelerator (ahora descontinuado)?

0

Tenía este problema, resultó ser un atributo OutputCache en una vista parcial.

Cuestiones relacionadas