Cookie de sesión de ASP.net perdida o eliminada

Question

Tengo un sitio ASP.NET 2.0 que almacena una ID de usuario en sesión para indicar que está conectado. En algunas situaciones, el usuario no parece estar conectado. I han estado monitoreando el tráfico en Fiddler, y algunos detalles que he encontrado:

• el problema es 100% repetible en una vieja computadora portátil de la mina cuando se ejecuta Internet Explorer 7 y el ordenador portátil del jefe de proyecto cuando se ejecuta Internet Explorer 7. El problema nunca ocurre en mi laptop actual con IE7, o cualquiera de estas laptops cuando ejecuto FF.
• El problema ocurre solo en la producción, no en el desarrollo, la organización interna o la organización del cliente. La producción es el único entorno de equilibrio de carga, pero la repetibilidad mencionada anteriormente me hace cuestionar el equilibrio de carga como un factor.
• Cuando la página que establece Session ("ID") = 1 envía una respuesta al cliente, puedo ver un encabezado "Set-Cookie" en todos los casos, que está creando la cookie ASP.Net_Session_Id (y es HttpOnly)
• Las solicitudes subsiguientes al servidor enviarán esa cookie en el encabezado de las máquinas que no muestran el problema, pero no en las máquinas que están, por lo que la cookie se borrará o se ignorará el encabezado "Set-Cookie".
• La manera de iniciar sesión funciona de la siguiente manera: una página en www.DomainX.com tiene un iframe. La fuente de ese iframe es una página en login.DomainY.com. Una variedad de páginas servidas desde login.DomainY.com lleva al usuario a través del proceso de inicio de sesión/registro. El paso final de login.DomainY.com es redireccionar a una página anterior en www.DomainX.com, incluida la identificación del usuario en la cadena de consulta. Esta página en www.DomainX.com normalmente almacena el ID en la sesión y luego ejecuta algunos JS para redirigir el documento de nivel superior a una página nueva, sacando así al usuario del iframe. Este es un proceso que ha funcionado durante varios años, con varios valores de DomainX.com. La única cosa que puede ser diferente aquí es que en este caso, el JS simplemente está destruyendo el iframe y algunos contienen div's.
• Otra diferencia que veo entre los escenarios donde ocurre el problema y donde no está es en las cookies de Google Analytics. Hay una diferencia cuando login.DomainY.com/FinalStep.aspx hace que se redirija a www.DomainX.com/SaveTheID.aspx dentro del iframe. Cuando el problema no ocurre, la solicitud de SaveTheID.aspx incluye una variedad de cookies de Google Analytics (__utma, __utmz, etc.). Cuando se produce el problema, esta solicitud no incluye todas las cookies de GA (faltan __utma, __utmz y __utmb).
• La producción es el único entorno donde login.DomainY.com se ejecuta bajo SSL, por lo que pensé que podría estar relacionado. Pero establecimos temporalmente nuestra copia provisional de login.DomainY.com para usar SSL, y eso no tuvo ningún efecto.

¿Alguna idea de qué podría causar esto?

Editar: el entorno de producción tiene dominios de www.DomainX.com y DomainX.com. Hay otro problema conocido con las cookies que no se establecen para ambos dominios. Es posible que esto esté relacionado, pero no podré probar hasta que ese arreglo vaya a prod.

Answer 1

Querrá echar un vistazo a su proveedor de estado de sesión para ver si funciona en los dos servidores/instancias de la aplicación .net. Si se establecen, por ejemplo, en inProc, definitivamente se encontrará con este problema ya que cada sesión estará vinculada al hilo en el que se creó. En su lugar, desea abstraer esto al servicio de estado asp.net al que ambas máquinas pueden acceder o incluso mejor debe usar una solución de almacenamiento en caché distribuida como el proyecto Microsoft Velocity que distribuirá las sesiones entre las dos máquinas en caso de que una se caiga.

Algunas otras maneras de lidiar con esto son usar sesiones adhesivas en el equilibrador de carga (no recomendado) o pasar a una sesión sin cookies que funcionaría pero que podría causarle dolores de cabeza a su código.

En nuestro negocio tenemos un servidor primario y secundario con un caché distribuido detrás de eso, de modo que si una máquina se cae, la otra puede hacerse cargo. Este mismo principio se aplica al equilibrio de carga y una vez que comience a tener más de una máquina o incluso más de una instancia en el grupo de aplicaciones, tendrá que codificar para esto.

Si usa Velocity para la sesión, asegúrese de que la memoria caché que seleccione para almacenar sus sesiones no sea desahuciable.

Answer 2

Creo que Middletone tiene razón, excepto que no explica por qué el problema no puede ser reprobado con Firefox. El equilibrador de carga es el sospechoso no.1; sería bueno ver si tiene una coartada al desconectar todos los servidores de la aplicación menos uno (si es factible, y durante un momento en que pueda manejar la carga) y ver si el problema aún existe. Si es así, no es el equilibrador de carga y puede comenzar a buscar en otro lado. Si no, es el balanceador de carga.

BTW: Las sesiones fijas son malas porque las sesiones que están en él no están protegidas por la redundancia. Además, el equilibrador de carga no puede distribuirse al servidor menos cargado en un momento determinado, solo puede decidir al inicio de una sesión y luego mantener al usuario donde se encuentra.

Si resulta que tiene aquí un problema de equilibrador de carga, lo primero que haría es activar la adherencia de la sesión y, a continuación, buscar otra solución con el relajante entorno de producción en funcionamiento.

Answer 3

Shoot, que debe haber perdido mi galleta y la capacidad para responder y editar ...

hice explorar el equilibrador de carga como el asunto un poco modificando mi archivo de hosts para apuntar directamente a las direcciones IP de cada de los servidores web, y eso no tuvo ningún efecto. Creo que el personal de TI del cliente va a negarse a pedir que se cancele el equilibrio de carga.

Tenemos un servidor de estado independiente en ejecución, y es el mismo que se ha utilizado durante algunos años en otros sitios alojados en los mismos servidores. No necesariamente sin problemas, pero sin un problema como este.

Como una tirita, actualmente estoy probando otros mecanismos de persistencia ...