Solución de problemas con la autenticación de formularios

Se aplica a: Internet Information Services

A menudo, al usar la autenticación de formularios en una aplicación web de ASP.NET, es necesario solucionar un problema que se produce cuando una solicitud nueva o continua se redirige intermitentemente a la página de inicio de sesión de la aplicación. Puede depurar este problema en el IDE de Visual Studio mediante la asociación de un depurador en un entorno de desarrollo. Sin embargo, en entornos de producción, la tarea se vuelve agitada y problemática. Para solucionar un problema aleatorio como este, debe registrar información relacionada con el problema para que pueda restringir la causa principal.

En este artículo se describe brevemente el concepto de autenticación de formularios. También se describen varios escenarios sobre un usuario que se redirige a la página de inicio de sesión y cómo capturar datos relevantes para aislar el problema. Además, también se describe cómo implementar una IHttpModule interfaz para registrar la información de autenticación de formularios.

Introducción a la autenticación de formularios de ASP.NET

La autenticación de formularios le permite autenticar a los usuarios mediante su propio código y, a continuación, mantener un token de autenticación en una cookie o en la dirección URL. La autenticación de formularios participa en el ciclo de vida de la página ASP.NET a través de la FormsAuthenticationModule clase . Puede acceder a la información y funcionalidades de autenticación de formularios mediante la FormsAuthentication clase .

Para usar la autenticación de formularios, cree una página de inicio de sesión que recopile las credenciales del usuario e incluya código para autenticar las credenciales. Normalmente, la aplicación se configura para redirigir las solicitudes a la página de inicio de sesión cuando los usuarios intentan acceder a un recurso protegido, como una página que requiere autenticación. Si las credenciales del usuario son válidas, puede llamar a métodos de la FormsAuthentication clase para redirigir la solicitud al recurso solicitado originalmente con un vale de autenticación (cookie) adecuado. Si no desea la redirección, puede obtener la cookie de autenticación de formularios o establecerla. En las solicitudes posteriores, el explorador pasa la cookie de autenticación con la solicitud, que luego omite la página de inicio de sesión.

De forma predeterminada, la FormsAuthenticationModule clase se agrega en el archivo Machine.config . La FormsAuthenticationModule clase administra el proceso de autenticación de formularios.

Puede ver la siguiente entrada en el archivo Machine.config :

<httpModule> 
  <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" />            
</httpModule>

Puede configurar la autenticación de formularios mediante el elemento de configuración de autenticación, por ejemplo, estableciendo una página de inicio de sesión. En el archivo de configuración, especifique una dirección URL para redirigir las solicitudes no autenticadas a la página de inicio de sesión.

Después de la autenticación correcta, el FormsAuthenticationModule módulo establece el valor de la propiedad User en una referencia al usuario autenticado. En el ejemplo de código siguiente se muestra cómo leer mediante programación la identidad del usuario autenticado por formularios.

String authUser2 = User.Identity.Name;

Una manera cómoda de trabajar con la autenticación de formularios es usar la suscripción de ASP.NET y controles de inicio de sesión de ASP.NET. ASP.NET pertenencia permite almacenar y administrar información de usuario e incluye métodos para autenticar a los usuarios. Los controles de inicio de sesión de ASP.NET funcionan con la suscripción de ASP.NET. Encapsulan la lógica para solicitar credenciales a los usuarios, validar usuarios, recuperar o reemplazar contraseñas, etc. En efecto, la suscripción de ASP.NET y los controles de inicio de sesión de ASP.NET proporcionan una capa de abstracción sobre la autenticación de formularios. Estas características reemplazan la mayoría o todo el trabajo que normalmente tendría que hacer para usar la autenticación de formularios.

Escenarios

A continuación se muestran escenarios para que una solicitud se redirija a la página de login.aspx :

Se pierde la cookie de autenticación de formularios.

Escenario 1

Inicia sesión en el sitio web. En algún momento, el cliente envía una solicitud al servidor y la FormsAuthenticationModule clase no recibe la cookie.

Escenario 2

La cookie de autenticación de formularios también se puede perder cuando se supera el límite de cookies del cliente. En Microsoft Internet Explorer, hay un límite de 20 cookies. Una vez que el contador alcance 20, las 19 cookies anteriores se quitan de la colección del cliente. Si se quita la cookie ASPXAUTH, se le redirigirá a la página de inicio de sesión cuando se procese la siguiente solicitud.

Escenario 3

Una vez que la solicitud deja el cliente, hay varias capas que pueden afectar a los paquetes que se envían. Para determinar si un dispositivo de red quita la cookie, debe capturar un seguimiento de red en el cliente y el servidor y, a continuación, buscar en el cuerpo de la solicitud de la cookie. Quiere ver la solicitud de cliente para asegurarse de que se envió la cookie y comprobar el seguimiento del servidor para asegurarse de que el servidor recibió la cookie.

Se agota el tiempo de espera del vale de autenticación de formularios

En ASP.NET 2.0 aplicaciones en adelante, de forma predeterminada, el valor de autenticación timeout de formularios ha cambiado a 30 minutos. Esto significa que después de 30 minutos de inactividad, se le pedirá que vuelva a iniciar sesión.

Nota:

Al acceder a un sitio web cada vez, se restablece el reloj de la ventana de 30 minutos. Solo si está inactivo hay un tiempo de espera.

Si desea cambiar el timeout valor para que sea más largo, puede cambiar fácilmente el valor en el timeout archivo web.config local (el timeout valor es en minutos):

<system.web> 
 <authentication mode="Forms">     
   <forms timeout="120"/>                 
 </authentication>
</system.web>

Escenario 4

La autenticación de formularios puede expirar antes del valor del timeout atributo definido en el archivo de configuración.

Si el vale de autenticación de formularios se genera manualmente, la timeout propiedad del vale invalida el valor establecido en el archivo de configuración. Por lo tanto, si ese valor es menor que el valor del archivo de configuración, el vale de autenticación de formularios expira antes del valor del atributo del archivo timeout de configuración y viceversa. Por ejemplo, supongamos que el FORMS atributo timeout se establece en 30 en el archivo Web.config y el valor de expiración del vale se establece en 20 minutos. En este caso, el vale de autenticación de formularios expira después de 20 minutos y, a continuación, tiene que volver a iniciar sesión.

Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket 
supplied has expired.

Escenario 5

En la aplicación web de ASP.NET 4, mediante la autenticación de formularios, el mensaje del registro de eventos indica:

Event code: 4005 
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.

Recopilación y solución de problemas de datos

Escenario de solución de problemas 1

Puede determinar si una solicitud no contiene la cookie habilitando el registro de cookies en Microsoft Internet Information Services (IIS). Para ello, siga los pasos que se indican a continuación:

  1. Abra Microsoft Management Console (MMC) de IIS.
  2. Haga clic con el botón derecho en el sitio web y seleccione Propiedades.
  3. Seleccione la pestaña Sitio web y, a continuación, seleccione Habilitar registro.
  4. Asegúrese de que el formato de registro sea el formato de archivo de registro extendido W3C.
  5. Selecciona Propiedades.
  6. Seleccione la pestaña Avanzadas y, a continuación, seleccione Propiedades extendidas.
  7. En Propiedades extendidas, active las casillas Cookie(cs(Cookie)) y Referer (cs(Referer)).

Después de que se produzca este problema, determine qué cliente tenía el problema y la dirección IP del cliente. Filtre el registro de IIS en la dirección IP de ese cliente y vea la <COOKIE> columna.

Nota:

Use analizador de registros para analizar los registros de IIS.

Después de tener la lista de solicitudes de un usuario específico, busque las solicitudes a la página de inicio de sesión. Sabrá que se redirigiron a esta página y desearía ver las solicitudes antes de que se produjera el redireccionamiento. Si ve algo similar al siguiente, el cliente no envió la cookie o la cookie se quitó en la red entre el cliente y el servidor.

Nota:

Es probable que la primera solicitud tenga una cookie de autenticación de formularios a menos que cree una cookie persistente. El registro de IIS solo mostrará las cookies que se recibieron en la solicitud. La primera solicitud para tener la cookie de autenticación de formularios después de un intento de inicio de sesión correcto.

Escenario de solución de problemas 2

Microsoft Internet Explorer cumple las siguientes limitaciones mínimas recomendadas de RFC 2109:

  • Al menos 300 cookies.
  • Al menos 4096 bytes por cookie (medida por el tamaño de los caracteres que componen la cookie que no es terminal en la descripción de sintaxis del encabezado Set-Cookie).
  • Al menos 20 cookies por host único o nombre de dominio.

La cookie de autenticación de formularios también se puede perder cuando se supera el límite de cookies del cliente. En Microsoft Internet Explorer, hay un límite de 20 cookies. Una vez que el contador alcance 20, las 19 cookies anteriores se quitan de la colección del cliente. Si se quita la cookie ASPXAUTH, se le redirigirá a la página de inicio de sesión cuando se procese la siguiente solicitud. Puede usar Fiddler para ver los encabezados de solicitud o respuesta HTTP para ver si recibe la cookie del cliente. Descargue Fiddler.

Inicie la herramienta Fiddler en el equipo cliente, quite los seguimientos HTTP existentes, acceda a la autenticación de formularios que implementa la aplicación e intente iniciar sesión en la aplicación y observe el tráfico HTTP en Fiddler para ver si hay un intercambio de cookies de autenticación de formularios que se producen entre el cliente y el servidor. Después de capturar el tráfico, haga doble clic en una solicitud y seleccione Encabezados para ver el encabezado Set-Cookie. Si realiza un seguimiento de un inicio de sesión correcto, verá el encabezado Set-Cookie en la respuesta de un inicio de sesión correcto.

De forma predeterminada, Internet Explorer puede almacenar un máximo de 20 cookies para cada dominio. Si un servidor del dominio envía más de 20 cookies a un equipo cliente, el explorador del equipo cliente descarta automáticamente algunas cookies antiguas.

Cada cookie consta de un único par nombre-valor. Este par puede ir seguido de pares de atributo-valor separados por punto y coma. Este límite se ha aumentado para simplificar el desarrollo y el hospedaje de aplicaciones web en dominios que deben usar muchas cookies. La instalación de la actualización 937143 aumenta el número de cookies que Internet Explorer puede almacenar para cada dominio de 20 a 50. Para obtener más información, consulte Preguntas más frecuentes sobre Internet Explorer y Microsoft Edge para profesionales de TI.

Escenario de solución de problemas 3

Una vez que la solicitud deja el cliente, hay varias capas que pueden afectar a los paquetes que se envían (firewalls, servidores proxy y equilibradores de carga). Para determinar si un dispositivo de red quita la cookie, debe capturar un seguimiento de red en el cliente y el servidor y, a continuación, buscar la cookie en el cuerpo de la solicitud. Es posible que desee examinar la solicitud de cliente para asegurarse de que se envió la cookie y, a continuación, comprobar el seguimiento del servidor para asegurarse de que el servidor recibió esa cookie.

Solicitud de cliente

Se trata de una GET solicitud después de que el usuario se haya autenticado. La información del vale de autenticación de formularios está resaltada en gris. Esto confirma que la información de la cookie dejó el cliente. Cuando usa una herramienta de captura de red, como WireShark, verá el tráfico que realmente pasó por el adaptador.

47 45 54 20 68 74 74 70-3a 2f 2f 6c 6f 63 61 6c   GET http://local
68 6f 73 74 2f 46 6f 72-6d 73 41 75 74 68 4c 6f   host/FormsAuthLo
67 54 65 73 74 2f 57 65-62 46 6f 72 6d 31 2e 61   gTest/WebForm1.a
73 70 78 20 48 54 54 50-2f 31 2e 31 0d 0a 41 63   spx HTTP/1.1..Ac
63 65 70 74 3a 20 69 6d-61 67 65 2f 67 69 66 2c   cept: image/gif,
…Other headers of the GET request…
63 68 65 0d 0a 43 6f 6f-6b 69 65 3a 20 2e 41 53   che..Cookie: .AS
50 58 41 55 54 48 3d 33-43 45 46 39 42 39 41 30   PXAUTH=3CEF9B9A0
43 33 37 41 44 46 36 33-45 36 42 44 33 37 42 36   C37ADF63E6BD37B6
39 43 44 41 32 35 30 30-30 46 38 30 37 32 38 46   9CDA25000F80728F
35 31 43 39 35 36 36 44-31 34 43 35 34 31 34 35   51C9566D14C54145
38 31 43 39 33 45 32 41-30 31 44 44 43 44 45 46   81C93E2A01DDCDEF
32 34 41 31 37 34 32 39-34 31 30 43 30 39 37 34   24A17429410C0974
42 33 45 43 42 30 36 34-32 32 38 45 33 35 33 39   B3ECB064228E3539
39 41 38 32 32 42 33 42-39 33 36 44 46 30 38 46   9A822B3B936DF08F
42 41 42 44 33 45 31 30-32 44 30 30 32 31 30 43   BABD3E102D00210C
32 45 31 33 39 38 30 37-39 42 32 33 35 32 39 46   2E1398079B23529F
34 46 35 44 37 34 41 3b-20 50 72 6f 66 69 6c 65   4F5D74A; Profile
3d 56 69 73 69 74 6f 72-49 64 3d 62 32 34 65 62   =VisitorId=b24eb

Representación del lado servidor

Cuando vea la solicitud que alcanzó el servidor, asegúrese de que el servidor recibió la misma información que envió el cliente. Si el servidor no recibió la misma información, debe investigar otros dispositivos de la red para determinar dónde se quitó la cookie.

Nota:

También se han producido instancias de filtros ISAPI que eliminan cookies. Si confirma que el servidor web recibió la cookie, pero la cookie no aparece en los registros de IIS, compruebe los filtros de ISAPI. Es posible que tenga que quitar los filtros para ver si se resuelve el problema.

Escenario de solución de problemas 5

  • Si el escenario implica una granja de servidores web, asegúrese de que los archivos de configuración de cada servidor de la granja de servidores web tengan el mismo valor para la clave de validación y las claves de descifrado, que se usan para el hash y el descifrado, respectivamente. Para mantener la coherencia en todos los servidores de la granja de servidores, use la siguiente machineKey:

    <machineKey validationKey="<yourKey>" decryptionKey="<yourKey>" validation="SHA1" />

    Para obtener más información sobre las claves de máquina, consulte Clave de máquina y Plan de seguridad de aplicaciones.

    Para obtener información sobre cómo generar claves de máquina, consulte Configuración de claves de máquina.

  • Compare los timeout valores de ambos formularios, es decir, el módulo de autenticación y el módulo de sesión, en todos los servidores web.

  • Compare la versión de System.Web.dll en la carpeta Framework para ASP.NET 4 entre todos los servidores web de la granja de servidores. Error de autenticación de formularios para la solicitud. El motivo es que el vale proporcionado no era válido. Esto sucede debido a que falta la actualización de confiabilidad 1 para MS .NET Framework 4 en uno de los servidores web.

  • Instale la actualización de confiabilidad 1 para .NET Framework 4 kb2533523 en el servidor que le faltaba y reinicie el servidor. Se ha corregido el problema. Para obtener más información, vea Reliability Update 1 for the .NET Framework 4 (Actualización de confiabilidad 1 para .NET Framework 4).

Más información

Aviso de declinación de responsabilidades sobre la información de terceros

Los productos de otros fabricantes que se mencionan en este artículo han sido creados por compañías independientes de Microsoft. Microsoft no ofrece ninguna garantía, ya sea implícita o de otro tipo, sobre la confiabilidad o el rendimiento de dichos productos.

  • Last updated on