Compartir a través de

Solución de problemas de autenticación de formularios

por Apurva Joshi

Herramientas usadas en este solucionador de problemas:

  • LogParser 2.2
  • Fiddler
  • Microsoft Network Monitor 3.4

Este material se proporciona únicamente con fines informativos. Microsoft no ofrece garantía alguna, ya sea expresa o implícita,

Información general

A menudo, al usar la autenticación de formularios en una aplicación web 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 fácilmente este problema en el IDE de Visual Studio adjuntando 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 esta guía del solucionador de problemas, describiremos brevemente el concepto de autenticación de formularios. A continuación, veremos qué escenarios conducen a que un usuario se redirija a la página de inicio de sesión y cómo capturar datos relevantes para aislar el problema. También trataremos cómo implementar una interfaz IHttpModule para registrar la información de autenticación de formularios.

Información general sobre la autenticación de formularios de ASP.NET Forms

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

Para usar la autenticación de formularios, cree una página de inicio de sesión que recopile las credenciales del usuario y que 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 clase FormsAuthentication para redirigir la solicitud al recurso solicitado originalmente con un vale de autenticación (cookie) adecuado. Si no desea el redireccionamiento, puede obtener la cookie de autenticación de formularios o establecerla. En las solicitudes posteriores, el explorador del usuario pasa la cookie de autenticación con la solicitud, que después omite la página de inicio de sesión.

De forma predeterminada, la clase FormsAuthenticationModule se agrega en el archivo Machine.config. La clase FormsAuthenticationModule administra el proceso formsAuthentication.

A continuación se muestra una entrada del archivo Machine.config:

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

La autenticación de formularios se configura mediante el elemento de configuración de autenticación. En el caso más sencillo, tiene 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. A continuación, defina credenciales válidas, ya sea en el archivo Web.config o en un archivo independiente. En el ejemplo siguiente se muestra una sección de un archivo de configuración que especifica una página de inicio de sesión y credenciales de autenticación para el método Authenticate. Las contraseñas se han cifrado mediante el método HashPasswordForStoringInConfigFile.

<authentication mode="Forms"> 
     <forms name="MyAuthCookie" loginUrl="/Login.aspx">     
       <credentials passwordFormat="SHA1">        
         <user name="Kim" password="07B7F3EE06F278DB966BE960E7CBBD103DF30CA6" />         
         <user name="John" password="BA56E5E0366D003E98EA1C7F04ABF8FCB3753889"/>         
       </credentials>
     </forms>
</authentication>

Después de la autenticación correcta, el módulo FormsAuthenticationModule 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 ASP.NET pertenencia y ASP.NET controles de inicio de sesión. ASP.NET pertenencia permite almacenar y administrar información de usuario e incluye métodos para autenticar a los usuarios. ASP.NET los controles de inicio de sesión funcionan con ASP.NET pertenencia. Encapsulan la lógica para solicitar credenciales a los usuarios, validar usuarios, recuperar o reemplazar contraseñas, etc. En efecto, ASP.NET pertenencia y ASP.NET controles de inicio de sesión 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

Motivos para que una solicitud se redirija a la página login.aspx

La cookie de autenticación de formularios se pierde

Escenario 1:

Un usuario inicia sesión en el sitio web. En algún momento, el cliente envía una solicitud al servidor y la clase FormsAuthenticationModule 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 creada la 20ª cookie en el cliente, las cookies anteriores se quitan de la colección del cliente. Si es . Se quita la cookie ASPXAUTH, el usuario se redirigirá a la página de inicio de sesión cuando se procese la siguiente solicitud.

Escenario 3:

Una vez que la solicitud abandona 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

Una cosa que debe tener en cuenta en ASP.NET 2.0 en adelante las aplicaciones, es que el valor de tiempo de espera de autenticación de formularios ha cambiado para que sea de 30 minutos de forma predeterminada. Esto significa que, después de 30 minutos de inactividad, se le pedirá al usuario que vuelva a iniciar sesión (tenga en cuenta que cada vez que alcanza el sitio el reloj de la ventana de 30 minutos se restablece, por lo que solo es si están inactivos, se agota el tiempo de espera).

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

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

Escenario 4:

La autenticación de formularios puede agotar el tiempo de espera antes del valor del atributo de tiempo de espera establecido en el archivo de configuración.

Si el vale de autenticación de formularios se genera manualmente, la propiedad de tiempo de espera del vale invalidará 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 expirará antes del valor del atributo de tiempo de espera del archivo de configuración y viceversa. Por ejemplo, supongamos que el <atributo de tiempo de espera forms> está establecido en 30 en el archivo Web.config y el valor Expiration del vale se establece en 20 minutos. En este caso, el vale de autenticación de formularios expirará después de 20 minutos y el usuario tendrá que volver a iniciar sesión después de eso.

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

Escenario 5:

En ASP.NET 4 aplicación web 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 hacerlo, siga estos pasos:

  • Abra IIS Microsoft Management Console (MMC).
  • Haga clic con el botón derecho en el sitio web y, a continuación, haga clic en Propiedades.
  • Haga clic en la pestaña Sitio web y, a continuación, haga clic en Habilitar registro.
  • Asegúrese de que el formato de registro es formato de archivo de registro extendido W3C.
  • Haga clic en Propiedades.
  • Haga clic en la pestaña Avanzadas y, a continuación, haga clic en Propiedades extendidas.
  • En Propiedades extendidas, haga clic para activar la casilla Cookie(cs(Cookie)) y la casilla De referencia (cs(Referer)).

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

Nota

Puede usar el analizador de registros para analizar los registros de IIS. Para descargar el analizador de registros, visite el siguiente sitio web de Microsoft:

https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24659

Una vez que tenga la lista de solicitudes de ese usuario específico, busque las solicitudes a la página de inicio de sesión. Sabe que se redirigiron a esta página y desea 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

La primera solicitud de ese usuario no es probable que tenga una cookie de autenticación de formularios a menos que esté creando una cookie persistente. El registro de IIS solo le mostrará las cookies recibidas en la solicitud. La primera solicitud para que la cookie de autenticación de formularios esté en la solicitud 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 (medido 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

Use el artículo siguiente para obtener más referencia: https://support.microsoft.com/kb/306070

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 creada la 20ª cookie en el cliente, las cookies anteriores se quitan de la colección del cliente. Si es . Se quita la cookie ASPXAUTH, el usuario se 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 http/respuesta y para ver si recibe la cookie del cliente o no. Descargue Fiddler desde la siguiente dirección URL:

http://fiddler2.com/fiddler2/

Inicie la herramienta fiddler en el equipo cliente, quite los seguimientos HTTP existentes, acceda a la aplicación que implementa la autenticación de formularios e intente iniciar sesión en la aplicación y observe el tráfico http en la herramienta fiddler para ver que 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, a continuación, haga clic en 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 estar 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 sobre esto, consulte el siguiente artículo:

https://support.microsoft.com/kb/941495

Escenario de solución de problemas 3:

Una vez que la solicitud sale del cliente, hay varias capas que pueden afectar a los paquetes que se envían (firewalls, servidores proxy y equilibradores de carga, etc.). 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 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 solicitud GET después de autenticar al usuario. La información del vale de autenticación de formularios está resaltada en gris. Esto confirma que la información de la cookie abandonó el cliente. Cuando se usa una herramienta de captura de red, como Netmon, se ve 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

Solicitud del lado servidor

Al examinar la solicitud que llegó al servidor, quiere asegurarse de que el servidor recibió la misma información que el cliente envió. 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 las 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 ha resuelto el problema.

Escenario de solución de problemas 5:

  • Si el escenario implica una granja de servidores web, las claves machine deben ser las mismas en todas partes. Use la clave de máquina siguiente para mantener la coherencia en todos los servidores de la granja de servidores:

    <machineKey validationKey="87AC8F432C8DB844A4EFD024301AC1AB5808BEE9D1870689B63794D33EE3B55CDB315BB480721A107187561F388C6BEF5B623BF31E2E725FC3F3F71A32BA5DFC" decryptionKey="E001A307CCC8B1ADEA2C55B1246CDCFE8579576997FF92E7" validation="SHA1" />

  • Compare los valores de tiempo de espera para el módulo de autenticación de formularios 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. Motivo: 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. https://support.microsoft.com/kb/2533523

Otros recursos