DetailPage-MSS-KB

Base de Dados de Conhecimento

ID do artigo: 910439 - Última revisão: quinta-feira, 30 de maio de 2013 - Revisão: 2.0

 
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 em futuros artigos do Knowledge Base e colunas de voz de suporte. Você pode enviar suas idéias e comentários usando o Peça para ele (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) formulário. Há também um link para o formulário na parte inferior desta coluna.

Nesta página

Bem-vindo à coluna voz de suporte do ASP.NET! Meu nome é Jerry Andrade. Foram com a Microsoft por 5 anos e passaram a maior parte do meu tempo concentra-se nas tecnologias relacionadas à Web como o Microsoft FrontPage e o novas tecnologias Microsoft SharePoint. Passei o último ano trabalhando com Microsoft ASP.NET como um engenheiro de suporte. Este mês em suporte de voz coluna, vou explicar como solucionar problemas de autenticação de formulários em 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 está aleatoriamente redirecionado para a página de login. Em um mundo ideal, isso problema poderia ocorrer de maneira que permitem que você facilmente anexar um depurador e captura o problema. Em ambientes de produção, no entanto, isso raramente é o caso. Para solucionar um problema aleatório como esse, você precisa registrar informações relacionadas ao problema, de modo que você pode restringir a raiz causa.

Nesta coluna, brevemente abordaremos o Conceito de autenticação de formulários. Em seguida, vamos ver em quais cenários levar a um usuário que está sendo redirecionado para a página de login e como capturar dados que é relevante para isolar o problema. Também abordaremos como implementar uma interface IHttpModule para registrar as informações de autenticação de formulários.

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

Quando um usuário se autentica em um site da Web usando a autenticação de formulários o servidor cria um cookie. O valor do cookie é um tíquete de autenticação de 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 de FormsAuthentication.

Esta é 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 autenticar usando a 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 é enviada.
  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 login.
  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 a implementação e uso 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/7t6b43z4.aspx)
. aspx de http://msdn2.microsoft.com/en-us/library/System.Web.Security.FormsAuthentication (vs.71) (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthentication(vs.71).aspx)
. aspx de http://msdn2.microsoft.com/en-us/library/System.Web.Security.FormsAuthenticationTicket (vs.71) (http://msdn2.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(vs.71).aspx)
Para obter mais informações sobre o compartilhamento de 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 (http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/formsauth.aspx)

Motivos para 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 no site da Web. Em algum momento, o cliente envia uma solicitação para o servidor e o Classe FormsAuthenticationModule não recebe o cookie. Você pode determinar se uma solicitação de usuário não contém o cookie, permitindo que o cookie fazendo logon nos Serviços de Informações da Internet da Microsoft (IIS). Para fazer isso, execute estas etapas:
  1. Abra o Console de gerenciamento Microsoft (MMC) do IIS.
  2. Clique no site e, em seguida, clique emPropriedades.
  3. Clique no Site da Web guia e clique Ativar Registro em log.
  4. Certifique-se de que é o formato de log Arquivo de Log estendido do W3C Formato.
  5. Clique em Propriedades.
  6. Clique no Avançado guia e cliquePropriedades estendidas.
  7. Em Propriedades estendidas, clique para selecionar o Cookie(CS(cookie)) caixa de seleção e o Referência (cs(Referer)) caixa de seleção.
Depois que esse problema ocorre, determinar qual cliente tinha o problema e o endereço IP do cliente. Filtrar o log do IIS no endereço IP do cliente e exibir o cookie> coluna.

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

Este é o primeiro login.
Recolher esta tabelaExpandir esta tabela
MétodoPáginaRespostaCookies
GET/Default.aspx302 (Redirecionar)Não Cookies
GET/Login.aspx200 (Sucesso)Não Cookies
POST/Login.aspx302 (Redirecionar)Não Cookies
GET/Default.aspx200 (Sucesso).ASPXAUTH
GET/SomePage.aspx302 (Redirecionar)Não .ASPXAUTH Cookie
Estas são outras solicitações, seguidas por uma solicitação para uma página no site sem o.Cookie ASPXAUTH.
Recolher esta tabelaExpandir esta tabela
MétodoPáginaRespostaCookies
GET/SomePage.aspx302 (Redirecionar)Não .ASPXAUTH Cookie
GET/Login.aspx200 (Sucesso)Não .ASPXAUTH Cookie
POST/Login.aspx302 (Redirecionar)Não .ASPXAUTH Cookie
GET/SomePage.aspx200 (Sucesso).ASPXAUTH

Observação A primeira solicitação do usuário não é provável que um forms cookie de autenticação, a menos que você estiver 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 um bem-sucedido tentativa de logon.
Cenário 2

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

Você pode solucionar esses dois cenários da mesma forma. Examinar a solicitação apenas antes do redirecionamento para a página de login. Se a solicitação para esta página gera cookies, 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:
306070  (http://support.microsoft.com/kb/306070/ ) Limites de tamanho e números de um cookie no Internet Explorer

Você pode usar o Fiddler para exibir os cabeçalhos HTTP que são enviados ao cliente. Depois de capturar o tráfego, clique duas vezes em uma solicitação e, em seguida, clique em Cabeçalhos Para ver o cabeçalho Set-Cookie. Se você rastrear um login bem-sucedido, você verá o cabeçalho Set-Cookie na resposta de um login bem-sucedido.

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

Após a solicitação deixa o cliente, existem várias camadas que pode afetar os pacotes que estão sendo enviados. Para determinar se é um dispositivo de rede Removendo o cookie, você precisa capturar um rastreamento de rede no cliente e servidor, e, em seguida, examine o corpo da solicitação para o cookie. Você deseja Examinar a solicitação do cliente para certificar-se de que o cookie foi enviado e verifique se o servidor rastreamento para certificar-se de que o servidor recebeu o cookie.

Solicitação do cliente

Esta é uma solicitação GET depois que o usuário foi autenticado. O informações de tíquetes de autenticação de formulários são realçadas em azul. Isso confirma que que as informações do cookie deixado o cliente. Quando você usa uma captura de rede ferramenta, como o Netmon, você verá o tráfego que realmente aconteceu por meio do 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 servidor

Quando você examinar a solicitação que acessou o servidor, você deseja certificar-se de que o servidor recebeu as mesmas informações que o cliente enviado. Se o servidor não recebeu as mesmas informações, você precisará investigar outros dispositivos sobre o rede para determinar onde o cookie foi removido.

Observação Também houve ocorrências de filtros ISAPI remover os cookies. Se você confirmar que o servidor Web recebeu o cookie, mas o cookie não está listado nos logs do IIS, verifique se os filtros ISAPI. Talvez você precise remover os filtros para ver se o problema é resolvido.

O tempo limite do tíquete de autenticação de formulários

A causa comum de um usuário seja redirecionado é se o autenticação de formulários tíquete expirou. A autenticação de formulários tíquete 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 o tempo de validade expirar. Por exemplo, você define 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 login, se o usuário visita o site após 2:20 PM.

Se você usar expiração sliding, o cenário é um pouco mais complicado. O cookie e a permissão resultante são atualizado se o usuário visitar o site após o tempo de expiração é metade expirado. Por exemplo, você define uma expiração de 20 minutos, usando a expiração deslizante. Um usuário visita o site às 2:00, e o usuário receberá um cookie é definido para expirar às 2:20 PM. A expiração é atualizada apenas se o usuário visitar o site após 2:10 horas. Se o usuário visitar o site às 14:09, o tíquete não é atualizado porque metade dos o tempo de expiração não passou. Se o usuário espera 12 minutos, visitando o site às 14:21, o tíquete será expirado. O usuário é redirecionado para o login página.

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

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 o aplicativo O arquivo Web. config para garantir que a autenticação de formulários está habilitado.
  • FormsAuthConfig.cs: A classe que lê informações a partir do Arquivo FormsAuthLogger.config.
  • Log.cs: O arquivo que aceita um stringbuilder e grava os valores um arquivo de log.
  • FormsAuthLogger.config: O arquivo XML que é lido pelo arquivo Log.cs. Isso arquivo tem que estar na pasta /bin com a DLL criada. 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 registrar apenas as solicitações de um cliente que é conhecido por Reproduza o problema. Isso reduz o tamanho do log.
    • Tipo de captura: Especifica onde salvar o arquivo. O padrão é a pasta Temporary ASP.NET Files, mas você pode salvá-lo em qualquer lugar desde que a conta de processo do operador tem a capacidade de gravar o pasta.
Observação Vou fornecer um link de download para o código fornecido no Arquivo FormsAuthLogger.zip.

Eu vai destacar as principais áreas:
  1. Crie 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 maneira podemos investigar cada solicitação e determinar se ele tem o cookie de autenticação de formulários e faça o FormsAuthenticationTicket se o cookie existe.
    public void Init(HttpApplication application) 
    {
    	//Wire up the BeginRequest event
    	application.BeginRequest += (new EventHandler(this.Application_BeginRequest));
    }
  3. Implemente 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, em seguida, descriptografar ele.
  5. Registrar os valores. É recomendável fazer o seguinte Além de informações de formulários. Isso irá ajudá-lo a alinhar seus formulários informações de autenticação para os logs do IIS, se necessário:
    • Data: Permite que você veja quando a solicitação foi feita no.
    • RequestType: Mostra se a solicitação é Get ou uma POST.
    • URL: Mostra o padrão de solicitações que antecederam o problema.
    • Referenciador
    • ClientIP: Une as solicitações para uma determinada cliente.

Como sempre, fique à vontade para enviar idéias sobre tópicos que você deseja abordado em colunas futuras ou na Base de dados de conhecimento usando o Peça para ele (http://support.microsoft.com/common/survey.aspx?scid=sw;en;1176&p0=&p1=&p2=&p3=&p4=) formulário.

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: 
kbtshoot kbiis kbcode kbasp kbmt KB910439 KbMtpt
Tradução automáticaTradução automática
IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.
Clique aqui para ver a versão em Inglês deste artigo: 910439  (http://support.microsoft.com/kb/910439/en-us/ )
Compartilhar
Opções de suporte adicionais
Fóruns de Suporte do Microsoft Community
Contate-nos diretamente
Localize um parceiro certificado da Microsoft
Microsoft Store