Solucionar problemas de autenticação de formulários

ID do artigo: 910439 - Exibir os produtos aos quais esse artigo se aplica.
Coluna de voz de suporte do ASP .NET

Solucionando problemas de autenticação de formulários

para personalizar esta coluna às suas necessidades, queremos convidá-lo para enviar suas idéias sobre tópicos que interessam a você e problemas que você deseja ver abordados artigos do Knowledge Base no futuro e colunas de voz de suporte. Você pode enviar suas idéias e comentários usando o formulário Ask For It. Há também um link para o formulário na parte inferior desta coluna.
Expandir tudo | Recolher tudo

Nesta página

Bem-vindo à coluna ASP.NET suporte voz! Meu nome é Jerry Andrade. Eu foram com a Microsoft por 5 anos e passaram a maior parte do meu tempo enfoca relacionada à Web tecnologias como o Microsoft FrontPage e as novas tecnologias Microsoft SharePoint. Passei o último ano trabalhando com Microsoft ASP.NET como um engenheiro de suporte. Este mês na Support Voice coluna, vou explicar como solucionar problemas de autenticação de formulários no Microsoft ASP.NET.

Solucionando problemas de autenticação de formulários

Quando você usa autenticação de formulários em um aplicativo ASP.NET, talvez seja necessário para solucionar um problema que ocorre quando o usuário aleatoriamente é redirecionado para a página de login. Em um mundo ideal, esse problema poderia ocorrer de uma maneira que permitiria que você facilmente anexar um depurador e captura o problema. Em ambientes de produção, entretanto, isso é raramente o caso. Para solucionar um problema aleatório como esse, você precisa fazer logon informações relacionadas ao problema para que você pode restringir a causa raiz.

Nesta coluna, abordaremos resumidamente o conceito de autenticação de formulários. Em seguida, veremos em quais cenários de levam a um usuário que está sendo redirecionado para a página de login e como capturar dados que são relevantes para isolar o problema. Também abordaremos como implementar uma interface IHttpModule para registrar informações de autenticação de formulários.

Visão geral de autenticação de formulários

Quando um usuário é autenticado em um site da Web usando autenticação de formulários, o servidor cria um cookie. O valor do cookie é um tíquete de autenticação formulários criptografado. O cookie é passado para o servidor em cada solicitação para o aplicativo e a classe FormsAuthenticationModule descriptografa o valor do cookie e determina se o usuário é válido ou não.

Por padrão, o FormsAuthenticationModule classe é adicionada no arquivo Machine.config. A classe FormsAuthenticationModule gerencia o processo FormsAuthentication.

A seguir está uma entrada do arquivo Machine.config:
<httpModule>
     ?other modules?
     <add name="FormsAuthentication"
         type="System.Web.Security.FormsAuthenticationModule" />
     ?other modules?
</httpModule>
o tráfego HTTP geral para a autenticação usando autenticação de formulários é semelhante à seguinte:
  1. O cliente envia um HTTP GET para default.aspx. Nenhum cookie de autenticação de formulários é enviado.
  2. O servidor envia uma resposta 302 (redirecionar) para login.aspx.
  3. O cliente envia um HTTP POST para login.aspx. Ele inclui as informações de logon.
  4. O servidor envia uma resposta 302 (redirecionar) para default.aspx. O cookie de autenticação de formulários está incluído.
  5. O cliente envia um HTTP GET para default.aspx. Isso inclui o cookie de autenticação de formulários.
Para obter mais informações sobre como implementar e usar a autenticação de formulários, visite os seguintes sites da MSDN:
http://msdn2.microsoft.com/en-us/library/7t6b43z4.aspx
http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication(vs.71).aspx
http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspx
Para obter mais informações sobre como compartilhar os cookies de autenticação de formulários, visite o seguinte site da Web do ASP.NET:
http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx

Razões que um usuário pode ser redirecionado para a página de login

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

Cenário 1

Nesse cenário, um usuário faz logon para o site da Web. Em algum momento, o cliente envia uma solicitação para o servidor e a classe FormsAuthenticationModule não recebe o cookie. Você pode determinar se uma solicitação de usuário não contém o cookie habilitando o cookie de logon no Microsoft Internet Information Services (IIS). Para fazer isso, execute estas etapas:
  1. Abra o IIS Microsoft Management Console (MMC).
  2. Clique com o botão direito do mouse no site e, em seguida, clique em Propriedades .
  3. Clique na guia Site e em seguida, clique em Ativar log .
  4. Verifique se o formato de log é o Formato de arquivo de log estendido do W3C .
  5. Clique em Propriedades .
  6. Clique na guia Avançado e clique em Propriedades estendidas .
  7. Em Propriedades estendidas , clique para selecionar a caixa de seleção Cookie(cs(Cookie)) e o Referer (cs(Referer)) caixa de seleção.
Depois que esse problema ocorre, determine qual cliente teve o problema e endereço IP do cliente. O IIS faça logon no endereço IP do cliente e modo de exibição de filtro de < cookie > coluna.

Observação Você pode usar o Log Parser para analisar os logs do IIS. Para baixar o Log Parser, visite o seguinte site da Microsoft:
http://www.microsoft.com/downloads/details.aspx?FamilyID=890cd06b-abf8-4c25-91b2-f8d975cf8c07
Depois de ter a lista de solicitações de usuário específico, procure as solicitações para a página de login. Você sabe que eles foram redirecionados para esta página e você deseja ver as solicitações antes de ocorrer o redirecionamento. Se você estiver vendo algo semelhante à seguinte, o cliente ou não enviou o cookie ou o cookie foi removido da rede entre o cliente e o servidor.

Este é o logon inicial.
Recolher esta tabelaExpandir esta tabela
método página resposta cookies
OBTER/Default.aspx302 (Redirecionar)Sem cookies
OBTER/Login.aspx200 (Êxito)Sem cookies
POSTAGEM/Login.aspx302 (Redirecionar)Sem cookies
OBTER/Default.aspx200 (Êxito).ASPXAUTH
OBTER/SomePage.aspx302 (Redirecionar)Nenhum cookie ASPXAUTH
Estas são outras solicitações, seguidas de uma solicitação para uma página no site sem cookie ASPXAUTH.
Recolher esta tabelaExpandir esta tabela
método página resposta cookies
OBTER/SomePage.aspx302 (Redirecionar)Nenhum cookie ASPXAUTH
OBTER/Login.aspx200 (Êxito)Nenhum cookie ASPXAUTH
POSTAGEM/Login.aspx302 (Redirecionar)Nenhum cookie ASPXAUTH
OBTER/SomePage.aspx200 (Êxito).ASPXAUTH

Observação A primeira solicitação do usuário não é provável que tem um cookie de autenticação de formulários, a menos que você está criando um cookie persistente. O log do IIS só mostrará os cookies que foram recebidos na solicitação. A primeira solicitação para que o cookie de autenticação de formulários estará na solicitação após uma tentativa de logon bem-sucedida.
Cenário 2

O cookie de autenticação de formulários também pode ser perdido quando cookie limite do cliente for excedido. No Microsoft Internet Explorer, há um limite de 20 cookies. Depois que o cookie 20 é criado no cliente, cookies anteriores são removidos da coleção do cliente. Se o cookie ASPXAUTH for removido, o usuário será redirecionado para a página de logon quando a próxima solicitação é processada.

Você pode solucionar esses dois cenários da mesma maneira. Examine a solicitação antes do redirecionamento para a página de logon. Se a solicitação para esta página gera cookies, isso será algo para investigar.

Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
306070Limites de números e tamanho de um cookie no Internet Explorer

Você pode usar o Fiddler para exibir os cabeçalhos HTTP que são enviados para o cliente. Após capturar o tráfego, clique duas vezes em uma solicitação e clique em cabeçalhos para ver o cabeçalho Set-cookie. Se você rastrear um logon bem-sucedido, você verá o cabeçalho Set-cookie na resposta de um logon bem-sucedida.

Para baixar o Fiddler, visite o seguinte site do Fiddler:
http://www.fiddlertool.com/fiddler/
Cenário 3

Depois que a solicitação deixa o 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, é necessário que capturar um rastreamento de rede no cliente e o servidor e, em seguida, examinar o corpo da solicitação para o cookie. Você deseja examinar a solicitação do cliente para garantir que o cookie foi enviado e verificar o rastreamento de servidor para certificar-se que o servidor recebeu o cookie.

solicitação do cliente

Isso é uma solicitação GET depois que o usuário tenha sido autenticado. As informações de permissão de autenticação de formulários são realçadas em azul. Isso confirma que o cookie informações à esquerda o cliente. When you use a network capture tool, like Netmon, you see the traffic that actually went through the adapter.
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
Server-side request

Quando você examinar a solicitação atingiu o servidor, você deseja garantir que o servidor recebeu as mesmas informações que o cliente enviado. Se o servidor não recebeu as mesmas informações, você precisa investigar outros dispositivos na rede para determinar onde o cookie foi removido.

Observação Também há instâncias 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 você precise remover os filtros para ver se o problema foi resolvido.

O tíquete de autenticação de formulários expira

A outra causa comum para um usuário a ser redirecionado é se o tíquete de autenticação de formulários expirou. O tíquete de autenticação de formulários pode tempo limite de duas maneiras. O primeiro cenário ocorre se você usar expiração absoluta. Com expiração absoluta, a permissão de autenticação expira quando expira o tempo de expiração. Por exemplo, você definir uma expiração de 20 minutos, e um usuário visita o site às 2: 00. O usuário será redirecionado para a página de logon se o usuário visitar o site após 14: 20.

Se você usar expiração sliding, o cenário é um pouco mais complicado. O cookie e a permissão resultante são atualizados quando o usuário visitar o site após a hora de vencimento expirado metade. Por exemplo, você definir uma expiração de 20 minutos usando a expiração deslizante. Um usuário visita o site às 2: 00, e o usuário recebe um cookie é configurado para expirar em 14: 20. A expiração será atualizada apenas se o usuário visitar o site após 14: 10. Se o usuário visitar o site em 14: 09, o tíquete não é atualizado porque metade do tempo de expiração não passou. Se o usuário aguarda, em seguida, 12 minutos, visitando o site em 14: 21, a permissão será ser expirada. O usuário é redirecionado para a página de login.

Uma maneira a abordagem esse tipo de problema é registrar as informações cookie e permissão do autenticação de formulários. Dessa forma, você pode ver a se o cookie foi recebido pelo IIS e quais são os valores. Você pode fazer isso escrevendo um HttpModule e conectando desse módulo no pipeline de solicitação. Você não precisará modificar o código do aplicativo para obter informações que necessárias.

O exemplo anexado funciona no Microsoft .NET Framework 1.1 e o .NET Framework 2.0 e tem comentários em todo. O exemplo inclui os seguintes arquivos:
  • FormsAuthEvents.cs: A classe que implementa IHttpModule e liga para o evento Application_BeginRequest .
  • FormsAuthInfo.cs: A classe que recupera o cookie e descriptografa o tíquete de autenticação de formulários. Ele também verifica arquivo de Web.config do aplicativo para garantir que a autenticação de formulários está habilitado.
  • FormsAuthConfig.cs: A classe que lê informações do arquivo FormsAuthLogger.config.
  • Log.cs: O arquivo que aceita um stringbuilder e grava os valores de check-out um arquivo de log.
  • FormsAuthLogger.config: O arquivo XML que é lido pelo arquivo Log.cs. Este arquivo deve ser na pasta /bin com a DLL de compilação. O arquivo permite que você configure o seguinte:
    • Filtro por IP: você pode filtrar a captura de dados por IP do cliente. Dessa forma, você pode fazer somente as solicitações a partir de um cliente que é conhecido para reproduzir o problema. Isso reduz o tamanho do log.
    • Tipo de captura: Isto especifica onde salvar o arquivo. O padrão é a pasta Temporary ASP.NET Files, mas você pode salvar isso em qualquer lugar, desde que a conta de processo do operador tem a capacidade de gravar para a pasta.
Observação Eu fornecerá um link de download para o código fornecido no arquivo FormsAuthLogger.zip.

Eu será destaque as áreas principais:
  1. Criar uma classe que implementa a interface IHttpModule .
    public class FormsAuthEvents : IHttpModule 
    {
    		?code?
    }
  2. Conectar o evento que você deseja examinar. Neste exemplo, estamos usando o evento Application_BeginRequest . Dessa forma, pode investigar cada solicitação de determinar se ele tem o cookie de autenticação de formulários e faça o FormsAuthenticationTicket se o cookie for.
    public void Init(HttpApplication application) 
    {
    	//Wire up the BeginRequest event
    	application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implementar o evento Application_BeginRequest .
    private void Application_BeginRequest(Object source, EventArgs e)
    {	
       ?code to log the ticket?
    }
    
  4. Recuperar o cookie de autenticação de formulários e descriptografá-lo.
  5. Faça os valores. Eu recomendo fazer o seguinte com as informações de formulários. Isso ajudará você a alinhar suas informações de autenticação de formulários para os logs do IIS, se necessário:
    • Data: Permite que você vê quando a solicitação fornecida.
    • RequestType: Mostra se a solicitação é um GET ou uma postagem.
    • URL: Mostra o padrão de solicitações que levaram ao problema.
    • Referenciador
    • ClientIP: Vincula nas solicitações a um cliente específico.
Para obter mais informações sobre autenticação de formulários, você pode baixar os arquivos FormsAuthLogger exemplo a seguir:
Recolher esta imagemExpandir esta imagem
Download
Download the FormsAuthLogger.exe package now.

Como sempre, vontade enviar idéias sobre tópicos desejado no futuro abordada colunas ou na Base de dados de Conhecimento usando o formulário Ask For It.

Propriedades

ID do artigo: 910439 - Última revisão: quinta-feira, 31 de maio de 2007 - Revisão: 1.5
A informação contida neste artigo aplica-se a:
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
  • Microsoft ASP.NET 2.0
Palavras-chave: 
kbmt kbtshoot kbiis kbcode kbasp KB910439 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 910439

Submeter comentários