Usuarios forzados a volver a iniciar sesión al azar, antes de que se alcancen los valores de tiempo de espera de sesión y autenticación

Question

Tengo reportes y quejas de mi usuario de que utilizarán una pantalla y recibirán una patada de regreso a la pantalla de inicio de sesión inmediatamente en su próximo solicitud. No sucede todo el tiempo, sino al azar. Después de consultar el servidor web, el error que aparece en el registro de eventos de la aplicación es:

Código de evento: 4005 Mensaje de evento: Error en la autenticación de formularios para la solicitud. Motivo: el boleto entregado ha expirado.

Todo lo que leo comienza con personas que preguntan acerca de los huertos web o el equilibrio de carga. No estamos usando ninguno de esos. Somos un único servidor de Windows 2003 (hardware de 32 bits, hardware de 64 bits) con IIS6. Este es el único sitio web en este servidor también.

Este comportamiento no genera ninguna excepción de aplicación o problema visible para el usuario. Simplemente se reinician en la pantalla de inicio de sesión y se les obliga a iniciar sesión. Como se puede imaginar, esto es extremadamente molesto y contraproducente para nuestros usuarios.

Esto es lo que he puesto en mi web.config para la aplicación en la raíz:

<authentication mode="Forms"> 
     <forms name=".TcaNet" 
     protection="All" 
     timeout="40" 
     loginUrl="~/Login.aspx" 
     defaultUrl="~/MyHome.aspx" 
     path="/" 
     slidingExpiration="true" 
     requireSSL="false" /> 
    </authentication> 

También he leído que si se ha configurado algunos lugares que ya no existen o son falsos usted podría tener problemas . Mis atributos de ruta son válidos todos los directorios por lo que no debería ser el problema:

<location path="js"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="images"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="anon"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="App_Themes"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 
    <location path="NonSSL"> 
    <system.web> 
     <authorization> 
     <allow users="*" /> 
     </authorization> 
    </system.web> 
    </location> 

La única cosa que no me queda claro es si en mi tiempo de espera en la propiedad formas para el boleto de autenticación tiene que ser la misma como el valor de tiempo de espera de mi sesión (definido en la configuración de la aplicación en IIS). He leído algunas cosas que dicen que debe tener un tiempo de espera de autenticación más corto (40) que el tiempo de espera de la sesión (45) para evitar posibles complicaciones. De cualquier manera, tenemos usuarios que reciben una patada en la pantalla de inicio de sesión un minuto o dos después de su última acción. Entonces la sesión definitivamente no debería estar por vencer.

Actualización 23/23/09: Desde entonces he establecido el tiempo de espera de la sesión y los valores de tiempo de espera del ticket de autenticación en ambos 45 y el problema parece estar sucediendo.

El único otro archivo web.config de la aplicación se encuentra en 1 directorio virtual que aloja el Servidor de comunidades. la configuración de autenticación de web.config que son los siguientes:

<authentication mode="Forms"> 
      <forms name=".TcaNet" 
      protection="All" 
      timeout="40" 
      loginUrl="~/Login.aspx" 
      defaultUrl="~/MyHome.aspx" 
      path="/" 
      slidingExpiration="true" 
      requireSSL="true" /> 
     </authentication> 

Y aunque no creo que se aplica a menos que esté en un jardín web, tengo tanto de los valores clave de la máquina establecidos en ambos archivos web.config para ser el mismo (eliminado por conveniencia):

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1" /> 

<machineKey 
     validationKey="<MYVALIDATIONKEYHERE>" 
     decryptionKey="<MYDECRYPTIONKEYHERE>" 
     validation="SHA1"/> 

Cualquier ayuda con esto sería muy apreciada. Este parece ser uno de esos problemas que arroja una tonelada de resultados de Google, ninguno de los cuales parece encajar en mi situación hasta el momento.

Answer 1

1.) Compruebe con qué frecuencia se recicla su proceso iis. (Encienda logging y check your settings). Después de un reciclaje, utilizando el valor predeterminado en la tienda de sesión de proc, la sesión se pierde.

2.) ¿Su aplicación genera hilos que pueden arrojar una excepción (que por cierto no se muestran al usuario)? Porque si esa situación existe, el iis recicla los procesos con mucha más frecuencia.

Answer 2

También puede valer la pena verificar la propiedad Procesos máximos de trabajo para su grupo de aplicaciones. Si está utilizando en la sesión de memoria y tiene más de uno como el proceso máximo de trabajo, puede encontrar problemas de sesión ya que la solicitud de los usuarios es manejada por un hilo diferente que desconoce su sesión.

Answer 3

Como ha notado que está utilizando un FQDN muy específico para su sitio, ¿tiene alguna otra aplicación .Net ejecutándose bajo el mismo FQDN con diferentes rutas virtuales? El nombre de la cookie de autenticación puede ser el mismo para ambas aplicaciones, pero el token será diferente. Entonces, si me conecto a www.dominio.com y luego a www.dominio.com/app2, ya no tendré la autenticación correcta para la aplicación1.

Answer 4

Acabo de terminar con este problema exacto, exactamente como se describe en la pregunta y el problema era que faltaba alguna configuración en web.config.

Al utilizar formsAuthentication, debe dejar de tener la autenticación de identificador de sesión, ya que la cookie ahora es responsable de ella.

Esta línea tiene que ser añadido (o actualizarán) en su web.config, en el elemento "system.web"

<sessionState mode="Off"> 

sessionState y FormsAuthentication no deben estar encendidos. No entiendo los detalles de cómo se interfieren entre sí, pero en este caso, produjo salidas al azar de usuarios aleatorios en momentos aleatorios.

Answer 5

Nuestro sitio ha tropezado con el mismo problema durante años, pero ayer encontramos una solución, vea my question. Como sugirió un comentarista, He intentado añadir esto a web.config:

<sessionState mode="InProc" timeout="60" /> 

Al parecer, el desbordamiento debe ser ajustado tanto en sessionState y en el billete. Ver también ms docu en https://msdn.microsoft.com/en-us/library/ms178586.aspx

Para medir con mayor precisión el tiempo de espera real, mientras que en el modo de depuración, lo encontré muy útil para agregar Debug.WriteLine llamadas en el archivo Global.asax.cs en los métodos Session_Start() y Session_End(), con el tiempo de milisegundos a agregar usando

string.Format("{0:HH:mm:ss.fff} - {1}", DateTime.Now, strMessage); 

para que pueda iniciar sesión, ir a almorzar, dejar que la sesión termine y leer las marcas de tiempo en algún momento conveniente en la ventana Salida de VisualStudio.