Asp.net forma una cookie de autenticación que no respeta el tiempo de espera con IIS7

authentication iis-7

Question

Las cookies de autenticación parecen agotar el tiempo de espera después de un corto período de tiempo (un día más o menos). Estoy usando Autenticación de formularios y tengo el tiempo de espera = "10080" con slidingExpiration = "false" en el web.config. Con esa configuración, la cookie debe caducar aproximadamente 7 días después de que el usuario se haya autenticado correctamente.

Esto funcionó como se anunció con IIS6, pero cuando moví el sitio a IIS7, la cookie caduca mucho más rápido. Confirmé este comportamiento en varias máquinas con IE y Firefox, lo que me llevó a pensar que se trata de una configuración de IIS7.

¿Hay alguna configuración oculta que sea específica de IIS7 relacionada con la autenticación? Todos los otros tipos de autenticación están deshabilitados para el sitio web, excepto para el seguimiento anónimo del usuario.

Answer 1

En primer lugar, debo decir que estas "directrices" son genéricas y no iis-7 exclusivas. En web.config en <system.web> tiene <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" timeout="130" cookieless="false"/> (que requiere el estado de sesión ASP.NET Servicio de servidor que se ejecuta en el <sessionState mode="InProc" timeout="130" cookieless="false"/> local) o <sessionState mode="InProc" timeout="130" cookieless="false"/> . La principal diferencia es que en InProc, los datos del estado de la sesión se colocan en el proceso de la aplicación. En el otro entorno, un servicio diferente está haciendo el almacenamiento, y su aplicación simplemente lo sondea para obtener los datos requeridos. Habiendo utilizado ambos (así como el modo de estado de sesión del servidor sql), el InProc es el menos confiable pero el más rápido. El servidor Sql es el más confiable y el más lento, y el modo StateServer está en algún punto intermedio, por lo que no es confiable solo en el caso de una falla de energía / sistema. Una vez dicho esto, debo decir que para el sitio con un bajo recuento de solicitudes, la penalización de rendimiento es insignificante.

Ahora, mi experiencia ha demostrado que InProc es bastante impredecible en cuanto a su estabilidad; Solía ​​tener el mismo problema contigo. Pude extender la estabilidad de la aplicación ajustando la configuración del grupo de aplicaciones, eliminé el problema por completo al cambiar a SessionState (que también permite bajar la aplicación y no perder los datos de estado de la sesión).

Los motivos por los que puede sufrir la estabilidad de la aplicación / sesión:

1. IIS y agrupación de aplicaciones. Cada directorio virtul de un sitio web se asigna a un grupo de aplicaciones (por defecto a "DefaultAppPool") que tiene una serie de configuraciones entre las que se define el intervalo en que el proceso se "recicla" y, como tal, se preservan los recursos del sistema. Si no cambia la configuración, la aplicación puede desencadenar uno de los criterios para la recicladora de procesos, lo que significa que su aplicación está reventada.

2. Antivirus En una aplicación ASP.NET si se toca el archivo web.config (y cualquier archivo .config del que dependa la aplicación), la aplicación se reinicia. Ahora hay casos en que un programa antivirus puede tocar el archivo web.config (por ejemplo, una vez al día) y, como tal, la aplicación se reinicia y los datos de la sesión se pierden.

3. Mala configuración Específicamente para la Autenticación de Formularios, la configuración y el comportamiento relacionados con el tiempo siempre dependen de la sesión web y la sesión de autenticación se encuentra bajo la sesión web.

Lo que no sé es si el módulo de Autenticación de formularios depende solo del dominio de la sesión o si también coloca datos en el dominio de la aplicación. Si es el segundo caso, es posible que tenga que desactivar todas las configuraciones de reciclaje en el grupo de aplicaciones, así como también verificar nuevamente la configuración / antivirus y quién almacena los datos de la sesión.

Answer 2

Establezca el estado de la sesión configurado en IIS como En proceso Use Cookies Tiempo de espera = su tiempo requerido Use la identidad del servidor para la suplantación

También establezca EnableSessionState en verdadero (que también es predeterminado)

Y lo más importante, ejecutar el grupo de aplicaciones en modo clásico.

Espero que tu problema solucione.

Answer 3

Hace poco tuve el mismo problema cuando mi sitio se agotaba cada 20 minutos a pesar de que establecía el tiempo de espera de la sesión en 2 horas. Descubrí que era porque el proceso de trabajo de IIS se agotaba cada 20 minutos: http://technet.microsoft.com/en-us/library/cc783089(WS.10).aspx

Answer 4

Según entiendo, las cookies han expirado por la parte consumidora: el navegador, lo que significa que IIS no tiene voz en esto.

Answer 5

La cookie de autenticación se cifra utilizando el valor machineKey del web.config local o el machine.config global. Si no se establece explícitamente tal clave, se generará automáticamente una clave, pero no se conservará en el disco; por lo tanto, cambiará siempre que la aplicación se reinicie o "recicle" debido a inactividad, y se creará una nueva clave en el disco. próximo golpe.

Resolver el problema es tan fácil como agregar una sección de configuración <machineKey> a web.config , o posiblemente (preferiblemente?) Al machine.config en el servidor (no probado):

<system.web>
  ...
  <machineKey 
    validationKey="..."
    decryptionKey="..."
    validation="SHA1"
    decryption="AES"/>
  ...
</system.web>

Google genera una clave aleatoria para los sitios que pueden generar esta sección por usted. Si su aplicación trata con información confidencial, es posible que desee crear las claves usted mismo.