Partilhar via

Solução de problemas de autenticação de formulários

Aplica-se a: Serviços de Informações da Internet

Muitas vezes, ao usar a Autenticação de Formulários em um aplicativo Web ASP.NET, é necessário solucionar um problema que ocorre quando uma solicitação nova ou contínua é redirecionada intermitentemente para a página de logon do aplicativo. Você pode depurar esse problema no IDE do Visual Studio anexando um depurador em um ambiente de desenvolvimento. Em ambientes de produção, no entanto, a tarefa se torna agitada e problemática. Para solucionar um problema aleatório como este, você precisa registrar informações relacionadas ao problema para que você possa restringir a causa raiz.

Este artigo discute brevemente o conceito de Autenticação de Formulários. Ele também discute vários cenários sobre um usuário sendo redirecionado para a página de logon e como capturar dados relevantes para isolar o problema. Além disso, ele também discute como implementar uma IHttpModule interface para registrar as informações de autenticação de formulários.

Visão geral da autenticação do ASP.NET Forms

A autenticação de formulários permite autenticar usuários usando seu próprio código e, em seguida, manter um token de autenticação em um cookie ou na URL. A autenticação de formulários participa do ciclo de vida da página ASP.NET por meio da FormsAuthenticationModule classe. Você pode acessar informações e recursos de autenticação de formulários usando a FormsAuthentication classe.

Para usar a autenticação de formulários, crie uma página de logon que colete credenciais do usuário e inclua código para autenticar as credenciais. Normalmente, você configura o aplicativo para redirecionar solicitações para a página de logon quando os usuários tentam acessar um recurso protegido, como uma página que requer autenticação. Se as credenciais do usuário forem válidas, você poderá chamar métodos da FormsAuthentication classe para redirecionar a solicitação de volta para o recurso solicitado originalmente com um tíquete de autenticação apropriado (cookie). Se você não quiser o redirecionamento, basta obter o cookie de autenticação de formulários ou configurá-lo. Em solicitações subsequentes, seu navegador passa o cookie de autenticação com a solicitação, que ignora a página de login.

Por padrão, a FormsAuthenticationModule classe é adicionada ao arquivo Machine.config . A FormsAuthenticationModule classe gerencia o processo de autenticação de formulários.

Você pode ver a seguinte entrada no arquivo Machine.config :

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

Você pode configurar a autenticação de formulários usando o elemento de configuração de autenticação, por exemplo, definindo uma página de logon. No arquivo de configuração, especifique uma URL para redirecionar solicitações não autenticadas para a página de login.

Após a autenticação bem-sucedida, o FormsAuthenticationModule módulo define o valor da propriedade User como uma referência ao usuário autenticado. O exemplo de código a seguir mostra como ler programaticamente a identidade do usuário autenticado por formulários.

String authUser2 = User.Identity.Name;

Uma maneira conveniente de trabalhar com autenticação de formulários é usar ASP.NET associação e ASP.NET controles de login. ASP.NET associação permite armazenar e gerenciar informações do usuário e inclui métodos para autenticar usuários. ASP.NET controles de login funcionam com ASP.NET associação. Eles encapsulam a lógica para solicitar credenciais aos usuários, validar usuários, recuperar ou substituir senhas e assim por diante. Na verdade, ASP.NET associação de ASP.NET controles de login fornecem uma camada de abstração sobre a autenticação de formulários. Esses recursos substituem a maior parte ou todo o trabalho que você normalmente teria que fazer para usar a autenticação de formulários.

Cenários

Veja a seguir os cenários para uma solicitação ser redirecionada para a página login.aspx :

O cookie de autenticação de formulários é perdido.

Cenário 1

Você faz logon no site. Em algum momento, o cliente envia uma solicitação ao servidor e a FormsAuthenticationModule classe não recebe o cookie.

Cenário 2

O cookie de autenticação de formulários também pode ser perdido quando o limite de cookies do cliente é excedido. No Microsoft Internet Explorer, há um limite de 20 cookies. Quando o contador atinge 20, os 19 cookies anteriores são removidos da coleção do cliente. Se o cookie ASPXAUTH for removido, você será redirecionado para a página de logon quando a próxima solicitação for processada.

Cenário 3

Depois que a solicitação sai do cliente, há várias camadas que podem afetar os pacotes que estão sendo enviados. Para determinar se um dispositivo de rede está removendo o cookie, você precisa capturar um rastreamento de rede no cliente e no servidor e, em seguida, procurar o cookie no corpo da solicitação. Você deseja examinar a solicitação do cliente para certificar-se de que o cookie foi enviado e verificar o rastreamento do servidor para certificar-se de que o servidor recebeu o cookie.

O ticket de autenticação de formulários expirou

Em ASP.NET aplicativos 2.0 em diante, por padrão, o valor de autenticação timeout de formulários foi alterado para 30 minutos. Isso significa que, após 30 minutos de inatividade, você será solicitado a fazer login novamente.

Observação

Quando você acessa um site a cada vez, o relógio da janela de 30 minutos é redefinido. Somente se estiver ocioso, há um tempo limite.

Se você quiser alterar o timeout valor para ser mais longo, poderá alterar facilmente o timeout valor em seu arquivo web.config local (o timeout valor está em minutos):

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

Cenário 4

A autenticação de formulário pode expirar antes do valor do atributo definido no arquivo de timeout configuração.

Se o tíquete de autenticação de formulários for gerado manualmente, a timeout propriedade do tíquete substituirá o valor definido no arquivo de configuração. Portanto, se esse valor for menor que o valor no arquivo de configuração, o tíquete de autenticação de formulários expirará antes do valor do atributo do arquivo timeout de configuração e vice-versa. Por exemplo, vamos supor que o FORMS atributo timeout esteja definido como 30 no arquivo Web.config e o valor de expiração do tíquete seja definido como 20 minutos. Nesse caso, o tíquete de autenticação de formulários expira após 20 minutos e, em seguida, você precisa fazer logon novamente.

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

Cenário 5

No aplicativo Web ASP.NET 4 usando autenticação de formulários, a mensagem de log de eventos diz:

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

Coleta de dados e solução de problemas

Solucionar problemas do cenário 1

Você pode determinar se uma solicitação não contém o cookie habilitando o log de cookies no IIS (Serviços de Informações da Internet) da Microsoft. Para fazer isso, siga estas etapas:

  1. Abra o MMC (Console de Gerenciamento Microsoft) do IIS.
  2. Clique com o botão direito do mouse no site e selecione Propriedades.
  3. Selecione a guia Site e, em seguida, selecione Habilitar Log.
  4. Certifique-se de que o formato de log seja o formato de arquivo de log estendido do W3C.
  5. Selecione Propriedades.
  6. Selecione a guia Avançado e, em seguida, selecione Propriedades Estendidas.
  7. Em Propriedades estendidas, marque as caixas de seleção Cookie(cs(Cookie)) e Referer (cs(Referer)).

Depois que esse problema ocorre, determine qual cliente teve o problema e o endereço IP desse cliente. Filtre o log do IIS no endereço IP desse cliente e exiba a <COOKIE> coluna.

Observação

Use o Analisador de Log para analisar os Logs do IIS.

Depois de ter a lista de solicitações de um usuário específico, pesquise as solicitações para a página de login. Você saberia que eles foram redirecionados para esta página e gostaria de ver as solicitações antes que o redirecionamento ocorresse. Se você vir algo semelhante ao seguinte, o cliente não enviou o cookie ou o cookie foi removido da rede entre o cliente e o servidor.

Observação

A primeira solicitação provavelmente não terá um cookie de autenticação de formulários, a menos que você esteja criando um cookie persistente. O log do IIS mostrará apenas os cookies que foram recebidos na solicitação. A primeira solicitação para ter o cookie de autenticação de formulários após uma tentativa de logon bem-sucedida.

Cenário de solução de problemas 2

O Microsoft Internet Explorer está em conformidade com as seguintes limitações mínimas recomendadas pela RFC 2109:

  • Pelo menos 300 biscoitos.
  • Pelo menos 4.096 bytes por cookie (conforme medido pelo tamanho dos caracteres que compõem o cookie não terminal na descrição da sintaxe do cabeçalho Set-Cookie).
  • Pelo menos 20 cookies por host ou nome de domínio exclusivo.

O cookie de autenticação de formulários também pode ser perdido quando o limite de cookies do cliente é excedido. No Microsoft Internet Explorer, há um limite de 20 cookies. Quando o contador atinge 20, os 19 cookies anteriores são removidos da coleção do cliente. Se o cookie ASPXAUTH for removido, você será redirecionado para a página de logon quando a próxima solicitação for processada. Você pode usar o Fiddler para ver a solicitação HTTP ou os cabeçalhos de resposta para ver se está recebendo o cookie do cliente. Baixe o Fiddler.

Inicie a ferramenta Fiddler no computador cliente, remova os rastreamentos HTTP existentes, acesse seu aplicativo implementando a autenticação de formulários e tente fazer logon no aplicativo e observe o tráfego HTTP no Fiddler para ver se há uma troca de cookie de autenticação de formulários acontecendo entre o cliente e o servidor. Depois de capturar o tráfego, clique duas vezes em uma solicitação e selecione Cabeçalhos para ver o cabeçalho Set-Cookie. Se você rastrear um logon bem-sucedido, verá o cabeçalho Set-Cookie na resposta de um logon bem-sucedido.

Por padrão, o Internet Explorer pode armazenar no máximo 20 cookies para cada domínio. Se um servidor no domínio enviar mais de 20 cookies para um computador cliente, o navegador no computador cliente descarta automaticamente alguns cookies antigos.

Cada cookie consiste em um único par nome-valor. Esse par pode ser seguido por pares atributo-valor separados por ponto-e-vírgula. Esse limite foi aumentado para simplificar o desenvolvimento e a hospedagem de aplicativos Web em domínios que devem usar muitos cookies. A instalação do 937143 de atualização aumenta o número de cookies que o Internet Explorer pode armazenar para cada domínio de 20 para 50. Para obter mais informações, consulte Perguntas frequentes sobre o Internet Explorer e o Microsoft Edge para profissionais de TI.

Cenário de solução de problemas 3

Depois que a solicitação sai do cliente, há várias camadas que podem afetar os pacotes que estão sendo enviados (firewalls, proxies e balanceadores de carga). Para determinar se um dispositivo de rede está removendo o cookie, você precisa capturar um rastreamento de rede no cliente e no servidor e, em seguida, procurar o cookie no corpo da solicitação. Talvez você queira examinar a solicitação do cliente para garantir que o cookie foi enviado e, em seguida, verifique o rastreamento do servidor para garantir que o servidor tenha recebido esse cookie.

Solicitação do cliente

Esta é uma GET solicitação após a autenticação do usuário. As informações do tíquete de autenticação de formulários são realçadas em cinza. Isso confirma que as informações do cookie saíram do cliente. Quando você usa uma ferramenta de captura de rede, como o WireShark, você vê o tráfego que realmente passou pelo 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

Solicitação do lado do servidor

Quando você vir a solicitação que chegou ao servidor, certifique-se de que o servidor recebeu as mesmas informações que o cliente enviou. Se o servidor não recebeu as mesmas informações, você precisará investigar outros dispositivos na rede para determinar onde o cookie foi removido.

Observação

Também houve casos de filtros ISAPI removendo cookies. Se você confirmar que o servidor Web recebeu o cookie, mas o cookie não está listado nos logs do IIS, verifique os filtros ISAPI. Talvez seja necessário remover os filtros para ver se o problema foi resolvido.

Cenário de solução de problemas 5

  • Se o cenário envolver um web farm, verifique se os arquivos de configuração em cada servidor no web farm têm o mesmo valor para a chave de validação e as chaves de descriptografia, que são usadas para hash e descriptografia, respectivamente. Para manter a consistência em todos os servidores do farm, use a seguinte machineKey:

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

    Para obter mais informações sobre chaves de máquina, consulte Chave de máquina e Planejar a segurança do aplicativo.

    Para saber como gerar chaves de máquina, consulte Configurações de chave de máquina.

  • Compare os timeout valores de ambos os formulários, ou seja, o módulo de autenticação e o módulo de sessão, em todos os servidores Web.

  • Compare a versão System.Web.dll na pasta Framework para o ASP.NET 4 entre todos os servidores Web no farm. Falha na autenticação de formulários para a solicitação. O motivo é que o bilhete fornecido era inválido. Isso acontece devido à falta da Atualização de Confiabilidade 1 para MS .NET Framework 4 em um dos servidores Web.

  • Instale a Atualização de Confiabilidade 1 para o .NET Framework 4 kb2533523 no servidor que estava faltando e reinicializou o servidor. O problema está corrigido. Para obter mais informações, consulte Atualização de confiabilidade 1 para o .NET Framework 4.

Mais informações

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

  • Last updated on