Uma visão geral da autenticação de formulários (C#)

por Scott Mitchell

Baixar código ou baixar PDF

Neste tutorial, vamos mudar de mera discussão para implementação; em particular, veremos como implementar a autenticação de formulários. O aplicativo Web que começamos a construir neste tutorial continuará a ser criado nos tutoriais subsequentes, à medida que mudarmos da autenticação de formulários simples para associação e funções.

Consulte este vídeo para obter mais informações sobre este tópico: usando a autenticação básica de formulários no ASP.net.

Introdução

No tutorial anterior , discutimos as várias opções de autenticação, autorização e conta de usuário fornecidas pelo ASP.net. Neste tutorial, vamos mudar de mera discussão para implementação; em particular, veremos como implementar a autenticação de formulários. O aplicativo Web que começamos a construir neste tutorial continuará a ser criado nos tutoriais subsequentes, à medida que mudarmos da autenticação de formulários simples para associação e funções.

Este tutorial começa com uma visão detalhada do fluxo de trabalho de autenticação de formulários, um tópico que abordamos no tutorial anterior. Depois disso, criaremos um site ASP.NET por meio do qual será possível demonstrar os conceitos da autenticação de formulários. Em seguida, configuraremos o site para usar a autenticação de formulários, criaremos uma página de logon simples e veremos como determinar, no código, se um usuário é autenticado e, nesse caso, o nome de usuário com o qual se conectou.

Entender o fluxo de trabalho de autenticação de formulários, habilitá-lo em um aplicativo Web e criar as páginas de logon e logoff são etapas vitais para criar um aplicativo ASP.NET que dá suporte a contas de usuário e autentica usuários por meio de uma página da Web. Por causa disso – e como esses tutoriais se baseiam em um do outro, eu o encorajava a trabalhar com este tutorial por completo antes de passar para o próximo, mesmo que você já tenha experiência com a configuração da autenticação de formulários nos projetos anteriores.

Noções básicas sobre o fluxo de trabalho de autenticação de formulários

Quando o tempo de execução ASP.NET processa uma solicitação de um recurso ASP.NET, como uma página ASP.NET ou um serviço Web ASP.NET, a solicitação gera vários eventos durante seu ciclo de vida. Há eventos gerados no início e no final da solicitação, aqueles gerados quando a solicitação está sendo autenticada e autorizada, um evento gerado no caso de uma exceção sem tratamento e assim por diante. Para ver uma lista completa dos eventos, consulte os eventos do objeto HttpApplication.

Módulos http são classes gerenciadas cujo código é executado em resposta a um evento específico no ciclo de vida da solicitação. O ASP.NET é fornecido com vários módulos HTTP que executam tarefas essenciais em segundo plano. Dois módulos HTTP internos que são especialmente relevantes para nossa discussão são:

  • FormsAuthenticationModule – autentica o usuário inspecionando o tíquete de autenticação de formulários, que normalmente é incluído na coleção de cookies do usuário. Se nenhum tíquete de autenticação de formulários estiver presente, o usuário será anônimo.
  • UrlAuthorizationModule – Determina se o usuário atual está autorizado ou não a acessar a URL solicitada. Esse módulo determina a autoridade consultando as regras de autorização especificadas nos arquivos de configuração do aplicativo. O ASP.NET também inclui o FileAuthorizationModule que determina a autoridade consultando as ACLs de arquivo (s) solicitadas.

As FormsAuthenticationModule tentativas de autenticar o usuário antes do UrlAuthorizationModule (e FileAuthorizationModule ) em execução. Se o usuário que está fazendo a solicitação não estiver autorizado a acessar o recurso solicitado, o módulo de autorização encerrará a solicitação e retornará um status de HTTP 401 não autorizado . Nos cenários de autenticação do Windows, o status HTTP 401 é retornado para o navegador. Esse código de status faz com que o navegador solicite suas credenciais ao usuário por meio de uma caixa de diálogo modal. Com a autenticação de formulários, no entanto, o status HTTP 401 não autorizado nunca é enviado para o navegador porque o FormsAuthenticationModule detecta esse status e o modifica para redirecionar o usuário para a página de logon (por meio de um status de redirecionamento HTTP 302 ).

A responsabilidade da página de logon é determinar se as credenciais do usuário são válidas e, nesse caso, criar um tíquete de autenticação de formulários e redirecionar o usuário de volta para a página que ele estava tentando visitar. O tíquete de autenticação é incluído em solicitações subsequentes para as páginas no site, que o FormsAuthenticationModule usa para identificar o usuário.

O fluxo de trabalho de autenticação de formulários

Figura 1: fluxo de trabalho de autenticação de formulários

Lembrando o tíquete de autenticação entre visitas à página

Após o logon, o tíquete de autenticação de formulários deve ser enviado de volta ao servidor Web em cada solicitação para que o usuário permaneça conectado enquanto navega no site. Normalmente, isso é feito colocando o tíquete de autenticação na coleção de cookies do usuário. Cookies são pequenos arquivos de texto que residem no computador do usuário e são transmitidos nos cabeçalhos HTTP em cada solicitação para o site que criou o cookie. Portanto, depois que o tíquete de autenticação de formulários tiver sido criado e armazenado nos cookies do navegador, cada visita subsequente ao site enviará o tíquete de autenticação junto com a solicitação, identificando, assim, o usuário.

Um aspecto dos cookies é a expiração, que é a data e a hora em que o navegador descarta o cookie. Quando o cookie de autenticação de formulários expira, o usuário não pode mais ser autenticado e, portanto, se torna anônimo. Quando um usuário está visitando de um terminal público, é provável que eles queiram que seu tíquete de autenticação expire quando eles fecham o navegador. No entanto, ao visitar de casa, esse mesmo usuário pode querer que o tíquete de autenticação seja lembrado entre reinicializações do navegador para que eles não precisem fazer logon novamente cada vez que visitarem o site. Essa decisão é geralmente feita pelo usuário na forma de uma caixa de seleção "lembrar-me" na página de logon. Na etapa 3, examinaremos como implementar uma caixa de seleção "lembrar-me" na página de logon. O tutorial a seguir aborda as configurações de tempo limite de tíquete de autenticação em detalhes.

Note

É possível que o agente do usuário usado para fazer logon no site do não seja compatível com cookies. Nesse caso, o ASP.NET pode usar tíquetes de autenticação de formulários sem cookie. Nesse modo, o tíquete de autenticação é codificado na URL. Veremos quando tíquetes de autenticação sem cookie são usados e como eles são criados e gerenciados no próximo tutorial.

O escopo da autenticação de formulários

O FormsAuthenticationModule é um código gerenciado que faz parte do tempo de execução do ASP.net. Antes da versão 7 do servidor Web serviços de informações da Internet (IIS) da Microsoft, havia uma barreira distinta entre o pipeline http do IIS e o pipeline do tempo de execução do ASP.net. Em suma, no IIS 6 e versões anteriores, o FormsAuthenticationModule só é executado quando uma solicitação é delegada do IIS para o tempo de execução ASP.net. Por padrão, o IIS processa o próprio conteúdo estático – como páginas HTML e arquivos CSS e de imagem – e só encaminha solicitações para o tempo de execução ASP.NET quando uma página com uma extensão de. aspx,. asmx ou. ashx é solicitada.

O IIS 7, no entanto, permite pipelines integrados do IIS e do ASP.NET. Com algumas definições de configuração, você pode configurar o IIS 7 para invocar o FormsAuthenticationModule para todas as solicitações. Além disso, com o IIS 7, você pode definir regras de autorização de URL para arquivos de qualquer tipo. Para obter mais informações, consulte mudanças entre a segurança do IIS6 e do IIS7, a segurança da plataforma Web e a compreensão daautorização de URL do IIS7.

Longa história, em versões anteriores ao IIS 7, você só pode usar a autenticação de formulários para proteger recursos manipulados pelo tempo de execução do ASP.NET. Da mesma forma, as regras de autorização de URL são aplicadas somente aos recursos manipulados pelo tempo de execução ASP.NET. Mas, com o IIS 7, é possível integrar o FormsAuthenticationModule e o UrlAuthorizationModule ao pipeline HTTP do IIS, estendendo assim essa funcionalidade para todas as solicitações.

Etapa 1: Criando um site do ASP.NET para esta série de tutoriais

Para alcançar o público mais amplo possível, o site do ASP.NET que criaremos em toda esta série será criado com a versão gratuita da Microsoft do Visual Studio 2008, o Visual Web developer 2008. Implementaremos o SqlMembershipProvider repositório de usuários em um banco de dados Microsoft SQL Server 2005 Express Edition . Se você estiver usando o Visual Studio 2005 ou uma edição diferente do Visual Studio 2008 ou SQL Server, não se preocupe – as etapas serão quase idênticas e qualquer diferença não trivial será indicada.

Note

O aplicativo Web de demonstração usado em cada tutorial está disponível como um download. Este aplicativo baixável foi criado com o Visual Web Developer 2008 destinado para a versão de .NET Framework 3,5. Como o aplicativo é destinado ao .NET 3,5, seu arquivo de Web.config inclui elementos de configuração adicionais de 3,5 específicos. Longa história, se você ainda tiver que instalar o .NET 3,5 em seu computador, o aplicativo Web para download não funcionará sem primeiro remover a marcação específica de 3,5 da Web.config.

Antes que possamos configurar a autenticação de formulários, primeiro precisamos de um site ASP.NET. Comece criando um novo site do ASP.NET baseado em sistema de arquivos. Para fazer isso, inicie o Visual Web Developer e, em seguida, vá para o menu arquivo e escolha novo site, exibindo a caixa de diálogo novo site da Web. Escolha o modelo de site do ASP.NET, defina a lista suspensa local para sistema de arquivos, escolha uma pasta para colocar o site e defina o idioma como C#. Isso criará um novo site com uma página ASP.NET. aspx padrão, uma pasta de _ dados de aplicativo e um arquivo de Web.config.

Note

O Visual Studio dá suporte a dois modos de gerenciamento de projeto: projetos de site e projetos de aplicativos Web. Projetos de site não têm um arquivo de projeto, enquanto projetos de aplicativos Web imitam a arquitetura do projeto no Visual Studio .NET 2002/2003 – eles incluem um arquivo de projeto e compilam o código-fonte do projeto em um único assembly, que é colocado na pasta/bin Inicialmente, o Visual Studio 2005 tem suporte apenas para projetos de site, embora o modelo de projeto de aplicativo Web tenha sido reintroduzido com o Service Pack 1; O Visual Studio 2008 oferece ambos os modelos de projeto. No entanto, as edições Visual Web Developer 2005 e 2008 oferecem suporte apenas a projetos de site. Usarei o modelo de projeto de site. Se você estiver usando uma edição não Express e quiser usar o modelo de projeto de aplicativo Web em vez disso, fique à vontade para fazer isso, mas lembre-se de que pode haver algumas discrepâncias entre o que você vê na tela e as etapas que devem ser executadas em comparação com as capturas de tela mostradas e as instruções fornecidas nesses tutoriais.

Criar um novo site da Web de System-Based de arquivo

Figura 2: criar um novo site de System-Based de arquivo (clique para exibir a imagem em tamanho normal)

Adicionando uma página mestra

Em seguida, adicione uma nova página mestra ao site no diretório raiz chamado site. master. As páginas mestras permitem que um desenvolvedor de página defina um modelo de todo o site que pode ser aplicado a páginas ASP.net. O principal benefício das páginas mestras é que a aparência geral do site pode ser definida em um único local, facilitando a atualização ou o ajuste do layout do site.

Adicionar uma página mestra denominada site. Master ao site

Figura 3: adicionar uma página mestra denominada site. Master ao site (clique para exibir a imagem em tamanho normal)

Defina o layout de página de todo o site aqui na página mestra. Você pode usar a modo de exibição de Design e adicionar quaisquer controles de layout ou Web necessários, ou pode adicionar manualmente a marcação à mão na exibição de origem. Defini o layout da minha página mestra para imitar o layout usado na série de tutoriais trabalhando com dados na ASP.NET 2,0 (consulte a Figura 4). A página mestra usa folhas de estilo em cascata para posicionamento e estilos com as configurações de CSS definidas no arquivo Style. css (que está incluído no download associado deste tutorial). Embora não seja possível determinar a partir da marcação mostrada abaixo, as regras de CSS são definidas de modo que o < conteúdo da div de navegação > seja absolutamente posicionado para que ele apareça à esquerda e tenha uma largura fixa de 200 pixels.

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="Site.master.cs" Inherits="Site" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
    <title>Forms Authentication, Authorization, and User Accounts</title>
    <link href="Styles.css" rel="stylesheet" type="text/css" />
</head>
<body>
    <div id="wrapper">
        <form id="form1" runat="server">
        
            <div id="header">
                <span class="title">User Account Tutorials</span>
            </div>
        
            <div id="content">
                <asp:contentplaceholder id="MainContent" runat="server">
                  <!-- Page-specific content will go here... -->
                </asp:contentplaceholder>
            </div>
            
            <div id="navigation">
                TODO: Menu will go here...
            </div>
        </form>
    </div>
</body>
</html>

Uma página mestra define o layout de página estática e as regiões que podem ser editadas pelas páginas ASP.NET que usam a página mestra. Essas regiões editáveis por conteúdo são indicadas pelo ContentPlaceHolder controle, que podem ser vistas na < div de conteúdo > . Nossa página mestra tem um único ContentPlaceHolder (mainContent), mas a página mestra pode ter vários ContentPlaceHolders.

Com a marcação inserida acima, alternar para o modo de exibição de Design mostra o layout da página mestra. Todas as páginas ASP.NET que usam essa página mestra terão esse layout uniforme, com a capacidade de especificar a marcação para a MainContent região.

A página mestra, quando exibida por meio do modo de exibição de design

Figura 4: a página mestra, quando exibida por meio do modo de exibição de design (clique para exibir a imagem em tamanho normal)

Criando páginas de conteúdo

Neste ponto, temos uma página default. aspx em nosso site, mas ela não usa a página mestra que acabamos de criar. Embora seja possível manipular a marcação declarativa de uma página da Web para usar uma página mestra, se a página não contiver qualquer conteúdo, ainda é mais fácil apenas excluir a página e adicioná-la novamente ao projeto, especificando a página mestra a ser usada. Portanto, comece excluindo Default. aspx do projeto.

Em seguida, clique com o botão direito do mouse no nome do projeto na Gerenciador de Soluções e escolha Adicionar um novo formulário da Web chamado Default. aspx. Desta vez, marque a caixa de seleção "selecionar página mestra" e escolha a página mestra site. Master da lista.

Adicione uma nova página default. aspx escolhendo para selecionar uma página mestra

Figura 5: adicionar uma nova página default. aspx escolhendo para selecionar uma página mestra (clique para exibir a imagem em tamanho normal)

Use a página mestra site. Master

Figura 6: usar a página mestra site. Master

Note

Se você estiver usando o modelo de projeto de aplicativo Web, a caixa de diálogo Adicionar novo item não inclui uma caixa de seleção "selecionar página mestra". Em vez disso, você precisa adicionar um item do tipo "formulário de conteúdo da Web". Depois de escolher a opção "formulário de conteúdo da Web" e clicar em Adicionar, o Visual Studio exibirá a mesma caixa de diálogo Selecionar um mestre mostrada na Figura 6.

A nova marcação declarativa da página default. aspx inclui apenas uma @Page diretiva que especifica o caminho para o arquivo da página mestra e um controle de conteúdo para o mainContent ContentPlaceHolder da página mestra.

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
</asp:Content>

Por enquanto, deixe default. aspx vazio. Voltaremos a ele mais tarde neste tutorial para adicionar conteúdo.

Note

Nossa página mestra inclui uma seção para um menu ou alguma outra interface de navegação. Criaremos uma interface desse tipo em um tutorial futuro.

Etapa 2: Habilitando a autenticação de formulários

Com o site do ASP.NET criado, nossa próxima tarefa é habilitar a autenticação de formulários. A configuração de autenticação do aplicativo é especificada por meio do <authentication> elemento em Web.config. O <authentication> elemento contém um único atributo chamado Mode que especifica o modelo de autenticação usado pelo aplicativo. Esse atributo pode ter um dos quatro valores a seguir:

  • Windows – conforme discutido no tutorial anterior, quando um aplicativo usa a autenticação do Windows, é responsabilidade do servidor Web autenticar o visitante, e isso geralmente é feito por meio da autenticação básica, Digest ou integrada do Windows.
  • Formulários– os usuários são autenticados por meio de um formulário em uma página da Web.
  • Passport– os usuários são autenticados usando o Microsoft Passport Network.
  • Nenhum– nenhum modelo de autenticação é usado; todos os visitantes são anônimos.

Por padrão, os aplicativos ASP.NET usam a autenticação do Windows. Para alterar o tipo de autenticação para autenticação de formulários, precisamos modificar o atributo de <authentication> modo do elemento para formulários.

Se seu projeto ainda não contiver um arquivo de Web.config, adicione um agora clicando com o botão direito do mouse no nome do projeto na Gerenciador de Soluções, escolhendo Adicionar novo item e, em seguida, adicionando um arquivo de configuração da Web.

Se seu projeto ainda não incluir Web.config, adicione-o agora

Figura 7: se seu projeto ainda não incluir Web.config, adicione-o agora (clique para exibir a imagem em tamanho normal)

Em seguida, localize o <authentication> elemento e atualize-o para usar a autenticação de formulários. Após essa alteração, a marcação do arquivo de Web.config deve ser semelhante ao seguinte:

<configuration>
    <system.web>
        ... Unrelated configuration settings and comments removed for brevity ...
        <!--
            The <authentication> section enables configuration 
            of the security authentication mode used by 
            ASP.NET to identify an incoming user. 
        -->
        <authentication mode="Forms" />
    </system.web>
</configuration>

Note

Como Web.config é um arquivo XML, o uso de maiúsculas e minúsculas é importante. Certifique-se de definir o atributo Mode como Forms, com um "F" maiúsculo. Se você usar um outro tipo de maiúscula, como "Forms", receberá um erro de configuração ao visitar o site por meio de um navegador.

O <authentication> elemento pode, opcionalmente, incluir um <forms> elemento filho que contém configurações específicas de autenticação de formulários. Por enquanto, vamos usar apenas as configurações de autenticação de formulários padrão. Exploraremos o <forms> elemento filho mais detalhadamente no próximo tutorial.

Etapa 3: criando a página de logon

Para oferecer suporte à autenticação de formulários, nosso site precisa de uma página de logon. Conforme discutido na seção "Noções básicas sobre o fluxo de trabalho de autenticação de formulários", o FormsAuthenticationModule redirecionará automaticamente o usuário para a página de logon se ele tentar acessar uma página que não está autorizada a exibir. Também há ASP.NET controles da Web que exibirão um link para a página de logon para usuários anônimos. Isso levanta a pergunta, "Qual é a URL da página de logon?"

Por padrão, o sistema de autenticação de formulários espera que a página de logon seja nomeada login. aspx e colocada no diretório raiz do aplicativo Web. Se você quiser usar uma URL de página de logon diferente, poderá fazê-lo especificando-a no Web.config. Veremos como fazer isso no tutorial subsequente.

A página de logon tem três responsabilidades:

  1. Forneça uma interface que permita ao visitante inserir suas credenciais.
  2. Determine se as credenciais enviadas são válidas.
  3. "Faça logon" do usuário criando o tíquete de autenticação de formulários.

Criando a interface do usuário da página de logon

Vamos começar a usar a primeira tarefa. Adicione uma nova página do ASP.NET ao diretório raiz do site chamado login. aspx e associe-a à página mestra do site. master.

Adicione uma nova página ASP.NET chamada Login. aspx

Figura 8: adicionar uma nova página ASP.net chamada Login. aspx (clique para exibir a imagem em tamanho normal)

A interface de página de logon típica consiste em duas caixas de Text: uma para o nome do usuário, uma para sua senha – e um botão para enviar o formulário. Os sites muitas vezes incluem uma caixa de seleção "lembrar-me" que, se marcada, persiste o tíquete de autenticação resultante entre reinicializações do navegador.

Adicione dois TextBoxes a login. aspx e defina suas ID Propriedades como nome de usuário e senha, respectivamente. Defina também TextMode a propriedade da senha como senha. Em seguida, adicione um controle de caixa de seleção, definindo sua ID propriedade como rememberMe e sua Text propriedade como "lembrar-me". Depois disso, adicione um botão chamado LoginButton cuja Text Propriedade esteja definida como "login". E, finalmente, adicione um controle de rótulo da Web e defina sua ID propriedade como InvalidCredentialsMessage, sua Text propriedade como "seu nome de usuário ou senha é inválido. Tente novamente. ", sua ForeColor propriedade para vermelho e sua Visible propriedade como false.

Neste ponto, sua tela deve ser semelhante à captura de tela na Figura 9, e a sintaxe declarativa da sua página deve ser semelhante ao seguinte:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Login.aspx.cs" Inherits="Login" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <h1>
        Login</h1>
    <p>
        Username:
        <asp:TextBox ID="UserName" runat="server"></asp:TextBox></p>
    <p>
        Password:
        <asp:TextBox ID="Password" runat="server" TextMode="Password"></asp:TextBox></p>
    <p>
        <asp:CheckBox ID="RememberMe" runat="server" Text="Remember Me" /> </p>
    <p>
        <asp:Button ID="LoginButton" runat="server" Text="Login" OnClick="LoginButton_Click" /> </p>
    <p>
        <asp:Label ID="InvalidCredentialsMessage" runat="server" ForeColor="Red" Text="Your username or password is invalid. Please try again."
            Visible="False"></asp:Label> </p>
</asp:Content>

A página de logon contém duas caixas de entrada, uma caixa de seleção, um botão e um rótulo

Figura 9: a página de logon contém duas caixas de entrada, uma caixa de seleção, um botão e um rótulo (clique para exibir a imagem em tamanho normal)

Por fim, crie um manipulador de eventos para o evento de clique do LoginButton. No designer, basta clicar duas vezes no controle Button para criar esse manipulador de eventos.

Determinando se as credenciais fornecidas são válidas

Agora, precisamos implementar a tarefa 2 no manipulador de eventos Click do botão – determinando se as credenciais fornecidas são válidas. Para fazer isso, precisa haver um armazenamento de usuário que contenha todas as credenciais dos usuários para que possamos determinar se as credenciais fornecidas correspondem a todas as credenciais conhecidas.

Antes do ASP.NET 2,0, os desenvolvedores eram responsáveis por implementar suas próprias lojas de usuários e escrever o código para validar as credenciais fornecidas no repositório. A maioria dos desenvolvedores implementaria o armazenamento de usuários em um banco de dados, criando uma tabela chamada usuários com colunas como nome de usuário, senha, email, LastLoginDate e assim por diante. Essa tabela, em seguida, teria um registro por conta de usuário. Verificar as credenciais fornecidas de um usuário envolveria consultar o banco de dados para obter um nome de usuário correspondente e, em seguida, garantir que a senha no banco de dados correspondesse à senha fornecida.

Com o ASP.NET 2,0, os desenvolvedores devem usar um dos provedores de associação para gerenciar o armazenamento do usuário. Nesta série de tutoriais, usaremos o SqlMembershipProvider, que usa um banco de dados SQL Server para o armazenamento do usuário. Ao usar o SqlMembershipProvider, precisamos implementar um esquema de banco de dados específico que inclui as tabelas, exibições e procedimentos armazenados esperados pelo provedor. Examinaremos como implementar esse esquema no tutorial *criando o esquema de associação no SQL Server _. Com o provedor de associação em vigor, validar as credenciais do usuário é tão simples quanto chamar o método ValidateUser (_username *, password)da classe Membership, que retorna um valor booliano que indica se a validade da combinação de nome de usuário e senha . Vendo como ainda não implementamos o repositório de usuários do SqlMembershipProvider, não podemos usar o método ValidateUser da classe Membership neste momento.

Em vez de levar o tempo para criar nossa própria tabela de banco de dados personalizada de usuários (que estaria obsoleta depois de implementarmos o SqlMembershipProvider), vamos codificar as credenciais válidas na própria página de logon. No manipulador de eventos de clique do LoginButton, adicione o seguinte código:

protected void LoginButton_Click(object sender, EventArgs e)
{
    // Three valid username/password pairs: Scott/password, Jisun/password, and Sam/password.
    string[] users = { "Scott", "Jisun", "Sam" };
    string[] passwords = { "password", "password", "password" };
    for (int i = 0; i < users.Length; i++)
    {
        bool validUsername = (string.Compare(UserName.Text, users[i], true) == 0);
        bool validPassword = (string.Compare(Password.Text, passwords[i], false) == 0);
        if (validUsername && validPassword)
        {
            // TODO: Log in the user...
            // TODO: Redirect them to the appropriate page
        }
    }
    // If we reach here, the user's credentials were invalid
    InvalidCredentialsMessage.Visible = true;
}

Como você pode ver, há três contas de usuário válidas – Scott, Jisun e Sam – e todas as três têm a mesma senha ("password"). O código percorre os usuários e as matrizes de senhas que procuram uma correspondência válida de nome de usuário e senha. Se o nome de usuário e a senha forem válidos, precisaremos fazer logon do usuário e redirecioná-los para a página apropriada. Se as credenciais forem inválidas, exibiremos o rótulo InvalidCredentialsMessage.

Quando um usuário insere credenciais válidas, mencionei que elas são redirecionadas para a "página apropriada". No entanto, qual é a página apropriada? Lembre-se de que quando um usuário visita uma página que não está autorizada a exibir, o FormsAuthenticationModule os redireciona automaticamente para a página de logon. Ao fazer isso, ele inclui a URL solicitada na QueryString por meio do parâmetro ReturnUrl. Ou seja, se um usuário tentou visitar ProtectedPage. aspx e não tiver autorização para fazer isso, o FormsAuthenticationModule o redirecionaria para:

Login. aspx? ReturnUrl = ProtectedPage. aspx

Após fazer logon com êxito, o usuário deve ser Redirecionado de volta para ProtectedPage. aspx. Como alternativa, os usuários podem visitar a página de logon em seu próprio Volition. Nesse caso, depois de fazer logon no usuário, eles devem ser enviados à página default. aspx da pasta raiz.

Registro em log no usuário

Supondo que as credenciais fornecidas sejam válidas, precisamos criar um tíquete de autenticação de formulários, registrando assim o usuário no site. A classe FormsAuthentication no namespace System. Web. Security fornece métodos asclassificados para fazer logon e fazer logoff de usuários por meio do sistema de autenticação de formulários. Embora haja vários métodos na classe FormsAuthentication, os três que estamos interessados nesse momento são:

  • GetAuthCookie (username, persistCookie) – cria um tíquete de autenticação de formulários para o nome de usuário fornecido. Em seguida, esse método cria e retorna um objeto HttpCookie que mantém o conteúdo do tíquete de autenticação. Se persistCookie for true, um cookie persistente será criado.
  • SetAuthCookie (username, persistCookie) – chama o método GetAuthCookie (username, persistCookie) para gerar o cookie de autenticação de formulários. Esse método adiciona o cookie retornado pelo GetAuthCookie à coleção de cookies (supondo que a autenticação de formulários baseada em cookies esteja sendo usada; caso contrário, esse método chama uma classe interna que manipula a lógica de tíquete sem cookie).
  • RedirectFromLoginPage (username, persistCookie) – esse método chama SetAuthCookie (username, persistCookie) e redireciona o usuário para a página apropriada.

GetAuthCookie é útil quando você precisa modificar o tíquete de autenticação antes de gravar o cookie na coleção de cookies. SetAuthCookie será útil se você quiser criar o tíquete de autenticação de formulários e adicioná-lo à coleção de cookies, mas não quiser redirecionar o usuário para a página apropriada. Talvez você queira mantê-los na página de logon ou enviá-los para algumas páginas alternativas.

Como queremos fazer logon no usuário e redirecioná-los para a página apropriada, vamos usar RedirectFromLoginPage. Atualize o manipulador de eventos de clique do LoginButton, substituindo as duas linhas de tarefas comentadas pela seguinte linha de código:

FormsAuthentication. RedirectFromLoginPage (UserName. Text, RememberMe. Checked);

Ao criar o tíquete de autenticação de formulários, usamos a propriedade Text da caixa de texto nome de usuário para o parâmetro nome de usuário do tíquete de autenticação de formulários e o estado marcado da caixa de seleção rememberMe para o parâmetro persistCookie .

Para testar a página de logon, visite-a em um navegador. Comece inserindo credenciais inválidas, como um nome de usuário de "verão" e uma senha de "incorreto". Ao clicar no botão login, um postback ocorrerá e o rótulo InvalidCredentialsMessage será exibido.

O rótulo InvalidCredentialsMessage é exibido ao inserir credenciais inválidas

Figura 10: o rótulo InvalidCredentialsMessage é exibido ao inserir credenciais inválidas (clique para exibir a imagem em tamanho normal)

Em seguida, insira credenciais válidas e clique no botão logon. Dessa vez, quando o postback ocorrer, um tíquete de autenticação de formulários será criado e você será redirecionado automaticamente de volta para default. aspx. Neste ponto, você fez logon no site, embora não haja nenhuma indicação visual para indicar que você está conectado no momento. Na etapa 4, veremos como determinar programaticamente se um usuário está conectado ou não, além de como identificar o usuário que está visitando a página.

A etapa 5 examina as técnicas para fazer o logoff de um usuário do site.

Protegendo a página de logon

Quando o usuário insere suas credenciais e envia o formulário de página de logon, as credenciais – incluindo sua senha – são transmitidas pela Internet para o servidor Web em texto sem formatação. Isso significa que qualquer hacker que fareja o tráfego de rede pode ver o nome de usuário e a senha. Para evitar isso, é essencial criptografar o tráfego de rede usando camadas de soquete seguro (SSL). Isso garantirá que as credenciais (bem como a marcação HTML da página inteira) sejam criptografadas desde o momento em que deixam o navegador até que sejam recebidas pelo servidor Web.

A menos que seu site contenha informações confidenciais, você só precisará usar SSL na página de logon e em outras páginas em que a senha do usuário, de outra forma, seria enviada pela rede em texto sem formatação. Você não precisa se preocupar em proteger o tíquete de autenticação de formulários, já que, por padrão, ele é criptografado e assinado digitalmente (para impedir a violação). Uma discussão mais completa sobre segurança de tíquete de autenticação de formulários é apresentada no tutorial a seguir.

Note

Muitos sites financeiros e médicos são configurados para usar SSL em todas as páginas acessíveis a usuários autenticados. Se você estiver criando um site desse tipo, poderá configurar o sistema de autenticação de formulários para que o tíquete de autenticação de formulários seja transmitido apenas por uma conexão segura.

Etapa 4: detectando visitantes autenticados e determinando sua identidade

Neste ponto, habilitamos a autenticação de formulários e criamos uma página de logon rudimentar, mas ainda temos que examinar como podemos determinar se um usuário é autenticado ou anônimo. Em determinados cenários, talvez você queira exibir dados ou informações diferentes, dependendo se um usuário autenticado ou anônimo está visitando a página. Além disso, muitas vezes precisamos saber a identidade do usuário autenticado.

Vamos aumentar a página default. aspx existente para ilustrar essas técnicas. Em Default. aspx, adicione dois controles de painel, um chamado AuthenticatedMessagePanel e outro chamado AnonymousMessagePanel. Adicione um controle rótulo chamado WelcomeBackMessage no primeiro painel. No segundo painel, adicione um controle de hiperlink, defina sua propriedade Text como "fazer logon" e sua propriedade NavigateUrl como "~/login.aspx". Neste ponto, a marcação declarativa para default. aspx deve ser semelhante ao seguinte:

<%@ Page Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="Untitled Page" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
    <asp:Panel runat="server" ID="AuthenticatedMessagePanel">
        <asp:Label runat="server" ID="WelcomeBackMessage"></asp:Label>
    </asp:Panel>
    
    <asp:Panel runat="Server" ID="AnonymousMessagePanel">
        <asp:HyperLink runat="server" ID="lnkLogin" Text="Log In" NavigateUrl="~/Login.aspx"></asp:HyperLink>
    </asp:Panel>
</asp:Content>

Como você já deve ter adivinhado agora, a ideia aqui é exibir apenas o AuthenticatedMessagePanel para os visitantes autenticados e apenas o AnonymousMessagePanel para os visitantes anônimos. Para fazer isso, precisamos definir essas propriedades visíveis de painéis, dependendo se o usuário estiver conectado ou não.

A Propriedade Request. IsAuthenticated retorna um valor booliano que indica se a solicitação foi autenticada. Insira o código a seguir no código do manipulador de eventos de carregamento de página _ :

protected void Page_Load(object sender, EventArgs e)
{
    if (Request.IsAuthenticated)
    {
        WelcomeBackMessage.Text = "Welcome back!";
    
        AuthenticatedMessagePanel.Visible = true;
        AnonymousMessagePanel.Visible = false;
    }
    else
    {
        AuthenticatedMessagePanel.Visible = false;
        AnonymousMessagePanel.Visible = true;
    }
}

Com esse código em vigor, visite default. aspx por meio de um navegador. Supondo que você ainda tenha feito logon, você verá um link para a página de logon (consulte a Figura 11). Clique nesse link e faça logon no site. Como vimos na etapa 3, depois de inserir suas credenciais, você retornará a default. aspx, mas desta vez a página mostra o "bem-vindo de volta!" mensagem (consulte a Figura 12).

Ao visitar anonimamente, um link de logon é exibido

Figura 11: ao visitar anonimamente, um link de logon é exibido

Os usuários autenticados são mostrados na

Figura 12: os usuários autenticados são mostrados "bem-vindo de volta!" Mensagem

Podemos determinar a identidade do usuário conectado no momento por meio da propriedade de usuáriodo objeto HttpContext. O objeto HttpContext representa informações sobre a solicitação atual e é a página inicial para esses objetos ASP.NET comuns como resposta, solicitação e sessão, entre outros. A propriedade User representa o contexto de segurança da solicitação HTTP atual e implementa a interface IPrincipal.

A propriedade User é definida pelo FormsAuthenticationModule. Especificamente, quando o FormsAuthenticationModule encontra um tíquete de autenticação de formulários na solicitação de entrada, ele cria um novo objeto GenericPrincipal e o atribui à propriedade User.

Os objetos principais (como GenericPrincipal) fornecem informações sobre a identidade do usuário e as funções às quais eles pertencem. A interface IPrincipal define dois membros:

Podemos determinar o nome do visitante atual usando o seguinte código:

Cadeia de caracteres currentUsersName = User.Identity.Name;

Ao usar a autenticação de formulários, um objeto FormsIdentity é criado para a propriedade Identity de GenericPrincipal. A classe FormsIdentity sempre retorna a cadeia de caracteres "Forms" para sua propriedade AuthenticationType e true para sua propriedade IsAuthenticated. A propriedade Name retorna o nome de usuário especificado ao criar o tíquete de autenticação de formulários. Além dessas três propriedades, FormsIdentity inclui acesso ao tíquete de autenticação subjacente por meio de sua Propriedade ticket. A propriedade ticket retorna um objeto do tipo FormsAuthenticationTicket, que tem propriedades como expiração, IsPersistent, emitido, nome e assim por diante.

O ponto importante a ser resumido aqui é que o parâmetro username especificado nos métodos FormsAuthentication. GetAuthCookie (username, PersistCookie), FormsAuthentication. SetAuthCookie (username, persistCookie) e FormsAuthentication. RedirectFromLoginPage (username, persistCookie) é o mesmo valor retornado por User.Identity.Name. Além disso, o tíquete de autenticação criado por esses métodos está disponível com a conversão de User. Identity em um objeto FormsIdentity e, em seguida, o acesso à propriedade ticket:

FormsIdentity ident = User.Identity as FormsIdentity;
FormsAuthenticationTicket authTicket = ident.Ticket;

Vamos fornecer uma mensagem mais personalizada em Default. aspx. Atualize o manipulador de eventos de carregamento de página _ para que a propriedade Text do rótulo WelcomeBackMessage seja atribuída à cadeia de caracteres "Welcome Back, username!"

WelcomeBackMessage. Text = "Welcome Back", + User.Identity.Name + "!";

A Figura 13 mostra o efeito dessa modificação (ao fazer logon como o usuário Scott).

A mensagem de boas-vindas inclui o nome do usuário conectado no momento

Figura 13: a mensagem de boas-vindas inclui o nome do usuário conectado no momento

Usando os controles LoginView e LoginName

Exibir conteúdo diferente para usuários autenticados e anônimos é um requisito comum; Portanto, está exibindo o nome do usuário conectado no momento. Por esse motivo, o ASP.NET inclui dois controles da Web que fornecem a mesma funcionalidade mostrada na Figura 13, mas sem a necessidade de escrever uma única linha de código.

O controle LoginView é um controle da Web baseado em modelo que torna mais fácil exibir dados diferentes para usuários autenticados e anônimos. O LoginView inclui dois modelos predefinidos:

  • AnonymousTemplate – qualquer marcação adicionada a esse modelo é exibida somente para visitantes anônimos.
  • LoggedInTemplate – a marcação deste modelo é mostrada somente para usuários autenticados.

Vamos adicionar o controle LoginView à página mestra do nosso site, site. master. Em vez de adicionar apenas o controle LoginView, no entanto, vamos adicionar um novo controle ContentPlaceHolder e, em seguida, colocar o controle LoginView dentro desse novo ContentPlaceHolder. A lógica para essa decisão se tornará aparente em breve.

Note

Além de AnonymousTemplate e LoggedInTemplate, o controle LoginView pode incluir modelos específicos de função. Modelos específicos de função mostram a marcação somente para os usuários que pertencem a uma função especificada. Examinaremos os recursos baseados em função do controle LoginView em um tutorial futuro.

Comece adicionando um ContentPlaceHolder chamado LoginContent à página mestra dentro do elemento de navegação < div > . Você pode simplesmente arrastar um controle ContentPlaceHolder da caixa de ferramentas para a exibição de origem, colocando a marcação resultante logo acima o menu "TODO: vai aqui..." texto.

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Em seguida, adicione um controle LoginView dentro do LoginContent ContentPlaceHolder. O conteúdo colocado nos controles ContentPlaceHolder da página mestra é considerado conteúdo padrão para o ContentPlaceHolder. Ou seja, as páginas do ASP.NET que usam essa página mestra podem especificar seu próprio conteúdo para cada ContentPlaceHolder ou usar o conteúdo padrão da página mestra.

O LoginView e outros controles relacionados ao logon estão localizados na guia login da caixa de ferramentas.

O controle LoginView na caixa de ferramentas

Figura 14: o controle LoginView na caixa de ferramentas

Em seguida, adicione dois < br/ > Elements imediatamente após o controle LoginView, mas ainda dentro do ContentPlaceHolder. Neste ponto, a < > marcação do elemento div de navegação deve ser semelhante ao seguinte:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
        </asp:LoginView>
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Os modelos de LoginView podem ser definidos no designer ou na marcação declarativa. No designer do Visual Studio, expanda a marca inteligente do LoginView, que lista os modelos configurados em uma lista suspensa. Digite o texto "Olá, estranho" no AnonymousTemplate; em seguida, adicione um controle HyperLink e defina suas propriedades Text e NavigateUrl como "log in" e "~/login.aspx", respectivamente.

Depois de configurar o AnonymousTemplate, alterne para o LoggedInTemplate e insira o texto "bem-vindo de volta". Em seguida, arraste um controle LoginName da caixa de ferramentas para o LoggedInTemplate, colocando-o imediatamente após o texto "bem-vindo de volta". O controle LoginName, como o nome indica, exibe o nome do usuário conectado no momento. Internamente, o controle LoginName simplesmente gera a propriedade User.Identity.Name

Depois de fazer essas adições aos modelos do LoginView, a marcação deve ser semelhante ao seguinte:

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Com essa adição à página mestra site. Master, cada página em nosso site exibirá uma mensagem diferente dependendo se o usuário for autenticado. A Figura 15 mostra a página default. aspx quando visitada por meio de um navegador pelo usuário Jisun. A mensagem "bem-vindo de volta, Jisun" é repetida duas vezes: uma vez na seção de navegação da página mestra à esquerda (por meio do controle LoginView que acabamos de adicionar) e uma vez na área de conteúdo do default. aspx (por meio de controles Panel e lógica programática).

O controle LoginView exibe

Figura 15: o controle LoginView exibe "Welcome Back, Jisun".

Como adicionamos o LoginView à página mestra, ele pode aparecer em cada página em nosso site. No entanto, pode haver páginas da Web em que não queremos mostrar essa mensagem. Uma dessas páginas é a página de logon, já que um link para a página de logon parece estar fora desse local. Como colocamos o controle LoginView em um ContentPlaceHolder na página mestra, podemos substituir essa marcação padrão em nossa página de conteúdo. Abra login. aspx e vá para o designer. Como não definimos explicitamente um controle de conteúdo em Login. aspx para o LoginContent ContentPlaceHolder na página mestra, a página de logon mostrará a marcação padrão da página mestra para este ContentPlaceHolder. Você pode ver isso por meio do designer – o LoginContent ContentPlaceHolder mostra a marcação padrão (o controle LoginView).

A página de logon mostra o conteúdo padrão para o LoginContent ContentPlaceHolder da página mestra

Figura 16: a página de logon mostra o conteúdo padrão para o LoginContent ContentPlaceHolder da página mestra (clique para exibir a imagem em tamanho normal)

Para substituir a marcação padrão para o LoginContent ContentPlaceHolder, basta clicar com o botão direito do mouse na região no designer e escolher a opção criar conteúdo personalizado no menu de contexto. (Ao usar o Visual Studio 2008, o ContentPlaceHolder inclui uma marca inteligente que, quando selecionada, oferece a mesma opção.) Isso adiciona um novo controle de conteúdo à marcação da página e, portanto, nos permite definir conteúdo personalizado para esta página. Você pode adicionar uma mensagem personalizada aqui, como "faça logon...", mas vamos deixar isso em branco.

Note

No Visual Studio 2005, a criação de conteúdo personalizado cria um controle de conteúdo vazio na página ASP.NET. No Visual Studio 2008, no entanto, a criação de conteúdo personalizado copia o conteúdo padrão da página mestra no controle de conteúdo recém-criado. Se você estiver usando o Visual Studio 2008, depois de criar o novo controle de conteúdo, certifique-se de limpar o conteúdo copiado da página mestra.

A figura 17 mostra a página login. aspx quando visitada em um navegador depois de fazer essa alteração. Observe que não há mensagem "Olá, estranho" ou "bem-vindo de volta, nome de usuário" no div de navegação à esquerda < > , pois há ao visitar default. aspx.

A página de logon oculta a marcação padrão do LoginContent ContentPlaceHolder

Figura 17: a página de logon oculta a marcação padrão do LoginContent ContentPlaceHolder (clique para exibir a imagem em tamanho normal)

Etapa 5: fazendo logoff

Na etapa 3, examinamos a criação de uma página de logon para fazer logon de um usuário no site, mas ainda assim veremos como fazer logoff de um usuário. Além dos métodos para registrar um usuário no, a classe FormsAuthentication também fornece um método de saída. O método de saída simplesmente destrói o tíquete de autenticação de formulários, registrando assim o usuário fora do site.

A oferta de um link de logoff é um recurso comum, que ASP.NET inclui um controle especificamente projetado para fazer logoff de um usuário. O controle LoginStatus exibe um LinkButton "login" ou "Logout", dependendo do status de autenticação do usuário. Um LinkButton "login" é renderizado para usuários anônimos, enquanto um LinkButton "Logout" é exibido para usuários autenticados. O texto para os LinkButtons "login" e "Logout" pode ser configurado por meio das propriedades LoginText e LogoutText de LoginStatus.

Clicar no LinkButton "login" causa um postback, do qual um redirecionamento é emitido para a página de logon. Clicar no LinkButton "Logout" faz com que o controle LoginStatus invoque o método FormsAuthentication. Sign e, em seguida, redireciona o usuário para uma página. A página para a qual o usuário desconectado é redirecionado depende da propriedade LogoutAction, que pode ser atribuída a um dos três valores a seguir:

  • Atualizar – o padrão; redireciona o usuário para a página que eles estavam visitando. Se a página que ele estava visitando não permitir usuários anônimos, o FormsAuthenticationModule redirecionará automaticamente o usuário para a página de logon.

Você pode estar curioso para saber por que um redirecionamento é executado aqui. Se o usuário quiser permanecer na mesma página, por que a necessidade do redirecionamento explícito? O motivo é que, quando o LinkButton "logoff" é clicado, o usuário ainda tem o tíquete de autenticação de formulários em sua coleção de cookies. Consequentemente, a solicitação de postback é uma solicitação autenticada. O controle LoginStatus chama o método SignOut, mas isso acontece depois que o FormsAuthenticationModule autenticou o usuário. Portanto, um redirecionamento explícito faz com que o navegador solicite novamente a página. No momento em que o navegador solicitar novamente a página, o tíquete de autenticação de formulários foi removido e, portanto, a solicitação de entrada é anônima.

  • Redirecionar – o usuário é redirecionado para a URL especificada pela propriedade LogoutPageUrl de LoginStatus.
  • RedirectToLoginPage – o usuário é redirecionado para a página de logon.

Vamos adicionar um controle LoginStatus à página mestra e configurá-lo para usar a opção de redirecionamento para enviar o usuário a uma página que exibe uma mensagem confirmando que eles foram desconectados. Comece criando uma página no diretório raiz chamado logout. aspx. Não se esqueça de associar esta página à página mestra do site. master. Em seguida, insira uma mensagem na marcação da página, explicando o usuário que foi desconectado.

Em seguida, retorne à página mestra site. Master e adicione um controle LoginStatus abaixo do LoginView no LoginContent ContentPlaceHolder. Defina a propriedade LogoutAction do controle LoginStatus para redirecionar e sua propriedade LogoutPageUrl como "~/logout.aspx".

<div id="navigation">
    <asp:ContentPlaceHolder ID="LoginContent" runat="server">
        <asp:LoginView ID="LoginView1" runat="server">
            <LoggedInTemplate>
                Welcome back,
                <asp:LoginName ID="LoginName1" runat="server" />.
            </LoggedInTemplate>
            <AnonymousTemplate>
                Hello, stranger.
                <asp:HyperLink ID="lnkLogin" runat="server" NavigateUrl="~/Login.aspx">Log In</asp:HyperLink>
            </AnonymousTemplate>
        </asp:LoginView>
        <br />
        <asp:LoginStatus ID="LoginStatus1" runat="server" LogoutAction="Redirect" LogoutPageUrl="~/Logout.aspx" />
        
        <br /><br />
    </asp:ContentPlaceHolder>
   
    TODO: Menu will go here...
</div>

Como o LoginStatus está fora do controle LoginView, ele será exibido para os usuários anônimos e autenticados, mas isso não ocorrerá porque o LoginStatus exibirá corretamente um LinkButton "login" ou "Logout". Com a adição do controle LoginStatus, o hiperlink "logon" no AnonymousTemplate é supérfluo, portanto, remova-o.

A Figura 18 mostra default. aspx quando o Jisun visita. Observe que a coluna à esquerda exibe a mensagem "bem-vindo de volta, Jisun", junto com um link para fazer logoff. Clicar no LinkButton logoff causa um postback, assina Jisun fora do sistema e, em seguida, redireciona-o para logout. aspx. Como a Figura 19 mostra, no momento em que Jisun acessa logout. aspx, ela já foi desconectada e, portanto, é anônima. Consequentemente, a coluna à esquerda mostra o texto "bem-vindo, estranho" e um link para a página de logon.

Default. aspx mostra

Figura 18: default. aspx mostra "Welcome Back, Jisun" junto com um LinkButton "Logout" (clique para exibir a imagem em tamanho normal)

Logout. aspx mostra

Figura 19: logout. aspx mostra "bem-vindo, estranho" juntamente com um "logon" do LinkButton (clique para exibir a imagem em tamanho normal)

Note

Recomendo que você personalize a página logout. aspx para ocultar o LoginContent ContentPlaceHolder da página mestra (como fizemos para o login. aspx na etapa 4). O motivo é que o LinkButton "login" processado pelo controle LoginStatus (aquele abaixo de "Hello, estranho") envia o usuário para a página de logon, passando a URL atual no parâmetro ReturnUrl QueryString. Em suma, se um usuário que fez logoff clicar no LinkButton "login" desse LoginStatus e, em seguida, fizer logon, ele será redirecionado para logout. aspx, o que poderia confundir facilmente o usuário.

Resumo

Neste tutorial, começamos com um exame do fluxo de trabalho de autenticação de formulários e, em seguida, desativamos a implementação de autenticação de formulários em um aplicativo ASP.NET. A autenticação de formulários é alimentada pelo FormsAuthenticationModule, que tem duas responsabilidades: identificar usuários com base em seu tíquete de autenticação de formulários e redirecionar usuários não autorizados para a página de logon.

A classe FormsAuthentication do .NET Framework inclui métodos para criar, inspecionar e remover tíquetes de autenticação de formulários. A propriedade Request. IsAuthenticated e o objeto user fornecem suporte de programação adicional para determinar se uma solicitação é autenticada e informações sobre a identidade do usuário. Também há os controles da Web LoginView, LoginStatus e LoginName, que oferecem aos desenvolvedores uma maneira rápida e sem código para executar muitas tarefas comuns relacionadas ao logon. Examinaremos esses e outros controles da Web relacionados ao logon com mais detalhes em Tutoriais futuros.

Este tutorial forneceu uma visão geral do curso de autenticação de formulários. Não examinamos as opções de configuração assorted, veja como os tíquetes de autenticação de formulários sem cookie funcionam ou explore como o ASP.NET protege o conteúdo do tíquete de autenticação de formulários.

Boa programação!

Leitura Adicional

Para obter mais informações sobre os tópicos discutidos neste tutorial, consulte os seguintes recursos:

Treinamento em vídeo sobre tópicos contidos neste tutorial

Sobre o autor

Scott Mitchell, autor de sete livros sobre ASP/ASP. net e fundador da 4guysfromrolla.com, tem trabalhado com tecnologias Web da Microsoft desde 1998. Scott trabalha como consultor, instrutor e escritor independentes. Seu livro mais recente é que a Sams ensina a ASP.NET 2,0 em 24 horas. Ele pode ser acessado em mitchell@4GuysFromRolla.com . ou por meio de seu blog, que pode ser encontrado em http://ScottOnWriting.NET .

Agradecimentos especiais a...

Esta série de tutoriais foi revisada por muitos revisores úteis. O revisor de cliente potencial deste tutorial foi que esta série de tutoriais foi revisada por muitos revisores úteis. Os revisores potenciais para este tutorial incluem Alicja Maziarz, John Suru e Teresa Murphy. Está interessado em revisar meus artigos futuros do MSDN? Nesse caso, me solte uma linha em mitchell@4GuysFromRolla.com .