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

por Scott Mitchell

Observação

Desde que este artigo foi escrito, os provedores de associação ASP.NET foram substituídos pelo ASP.NET Identity. É altamente recomendável atualizar aplicativos para usar a plataforma ASP.NET Identity em vez dos provedores de associação apresentados no momento em que este artigo foi escrito. ASP.NET Identity tem várias vantagens em relação ao sistema de associação ASP.NET, incluindo:

• Melhor desempenho
• Extensibilidade e testabilidade aprimoradas
• Suporte para OAuth, OpenID Connect e autenticação de dois fatores
• Suporte à identidade baseada em declarações
• Melhor interoperabilidade com ASP.Net Core

Baixar código ou baixar PDF

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

Confira este vídeo para obter mais informações sobre este tópico: Usando a Autenticação de Formulários Básicos 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, examinaremos a implementação da autenticação de formulários. O aplicativo Web que começamos a construir neste tutorial continuará a ser criado nos tutoriais subsequentes, à medida que passarmos da autenticação de formulários simples para associação e funções.

Este tutorial começa com uma análise 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 demo os conceitos de 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 está autenticado e, nesse caso, o nome de usuário com o qual ele fez logon.

Entender o fluxo de trabalho de autenticação de formulários, habilitá-lo em um aplicativo Web e criar as páginas de login e logoff são etapas vitais na criação de 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 porque esses tutoriais se baseiam uns nos outros – eu incentivaria você a trabalhar neste tutorial na íntegra antes de passar para o próximo, mesmo que você já tenha experiência em configurar a autenticação de formulários em projetos anteriores.

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

Quando o ASP.NET runtime processa uma solicitação para um recurso de ASP.NET, como uma página ASP.NET ou ASP.NET serviço Web, a solicitação gera uma série de eventos durante seu ciclo de vida. Há eventos gerados no início e no final da solicitação, os 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 listagem 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. ASP.NET é fornecido com vários módulos HTTP que executam tarefas essenciais nos bastidores. 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. Este módulo determina a autoridade consultando as regras de autorização especificadas nos arquivos de configuração do aplicativo. ASP.NET também inclui o FileAuthorizationModule que determina a autoridade consultando as ACLs dos arquivos solicitados.

A FormsAuthenticationModule tenta autenticar o usuário antes da execução de UrlAuthorizationModule (e FileAuthorizationModule). 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 HTTP 401 Não autorizado . Em 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 ao usuário suas credenciais por meio de uma caixa de diálogo modal. No entanto, com a autenticação de formulários, o status HTTP 401 Não autorizado nunca é enviado ao 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 às páginas do site, que o FormsAuthenticationModule usa para identificar o usuário.

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

Lembrando o token de autenticação nas visitas às páginas

Depois de fazer 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 pelo site. Isso normalmente é feito colocando o tíquete de autenticação na coleção de cookies do usuário. Os 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 a esse 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, tornar-se anônimo. Quando um usuário está visitando de um terminal público, é provável que ele queira que seu tíquete de autenticação expire quando fechar o navegador. Ao visitar de casa, no entanto, esse mesmo usuário pode querer que o tíquete de autenticação seja lembrado em todas as reinicializações do navegador para que ele não precise fazer logon novamente sempre que visitar o site. Essa decisão geralmente é tomada pelo usuário na forma de uma caixa de seleção "Lembre-se de mim" na página de logon. Na Etapa 3, examinaremos como implementar uma caixa de seleção "Lembre-se de mim" na página de logon. O tutorial a seguir aborda detalhadamente as configurações de tempo limite do tíquete de autenticação.

Observação

É possível que o agente de usuário usado para fazer logon no site não dê suporte a cookies. Nesse caso, 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. Examinaremos quando os 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 runtime do ASP.NET. Antes da versão 7 do servidor Web dos Serviços de Informações da Internet (IIS) da Microsoft, havia uma barreira distinta entre o pipeline HTTP do IIS e o pipeline do ASP.NET runtime. Em suma, no IIS 6 e anterior, o FormsAuthenticationModule apenas é executado quando uma solicitação é delegada do IIS para o tempo de execução do ASP.NET. Por padrão, o IIS processa o conteúdo estático em si – como páginas HTML e CSS e arquivos de imagem – e apenas entrega solicitações para o runtime ASP.NET quando uma página com uma extensão de .aspx, .asmx ou .ashx é solicitada.

O IIS 7, no entanto, permite pipelines de IIS e ASP.NET integrados. Com algumas configurações, 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 Alterações entre a segurança do IIS6 e do IIS7, a segurança da plataforma Web e a compreensão da autorização de URL do IIS7.

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

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

Para alcançar o público mais amplo possível, o ASP.NET site que criaremos ao longo desta série será criado com a versão gratuita da Microsoft do Visual Studio 2008, Visual Web Developer 2008. Implementaremos o repositório de SqlMembershipProvider usuários em um banco de dados do 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 quaisquer diferenças não triviais serão apontadas.

Observação

O aplicativo Web de demonstração usado em cada tutorial está disponível como download. Este aplicativo para download foi criado com o Visual Web Developer 2008 direcionado para o .NET Framework versão 3.5. Como o aplicativo é direcionado para o .NET 3.5, seu arquivo Web.config inclui elementos de configuração adicionais e específicos de 3,5. Resumindo, se você ainda não tiver instalado o .NET 3.5 em seu computador, o aplicativo Web para download não funcionará sem remover primeiro a marcação específica de 3,5 do Web.config.

Antes de configurarmos a autenticação de formulários, primeiro precisamos de um site ASP.NET. Comece criando um novo site de ASP.NET baseado em sistema de arquivos. Para fazer isso, inicie o Visual Web Developer e vá para o menu Arquivo e escolha Novo Site da Web, exibindo a caixa de diálogo Novo Site da Web. Escolha o modelo ASP.NET Site, defina a lista suspensa Local como 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 Default.aspx ASP.NET, uma pasta App_Data e um arquivo Web.config.

Observação

O Visual Studio dá suporte a dois modos de gerenciamento de projetos: Projetos de Site e Projetos de Aplicativo Web. Os Projetos de Site não têm um arquivo de projeto, enquanto os Projetos de Aplicativo 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 só tinha suporte para projetos de site, embora o modelo do Projeto de Aplicativo Web tenha sido reintroduzido com o Service Pack 1; O Visual Studio 2008 oferece ambos os modelos de projeto. As edições do Visual Web Developer 2005 e 2008, no entanto, só dão suporte a Projetos de Site. Eu usarei o modelo do projeto de site. Se você estiver usando uma edição não Express e quiser usar o modelo do Projeto de Aplicativo Web , fique à vontade para fazer isso, mas esteja ciente de que pode haver algumas discrepâncias entre o que você vê em sua tela e as etapas que você deve executar em comparação com as capturas de tela mostradas e as instruções fornecidas nestes tutoriais.

Figura 2: Criar um novo arquivo System-Based Web Site (Clique aqui para ver a imagem em tamanho real)

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 ajuste do layout do site.

Figura 3: Adicionar uma página mestra denominada Site.master ao Site (clique para exibir a imagem em tamanho real)

Defina o layout da página em todo o site aqui na página mestra. Você pode usar a exibição Design e adicionar qualquer layout ou controle Web necessário, ou adicionar a marcação manualmente no modo de exibição Origem. Estruturei o layout da minha página mestra para imitar o layout usado em meu trabalho com dados em ASP.NET série de tutoriais 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 você não possa perceber pela marcação mostrada abaixo, as regras CSS são definidas de modo que o conteúdo do elemento div de navegação esteja posicionado de forma absoluta, de modo que 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 da 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 de conteúdo são indicadas pelo ContentPlaceHolder controle, que pode ser visto dentro do <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 design mostra o layout da página mestre. Quaisquer páginas ASP.NET que usem esta página mestra terão esse layout uniforme, com a capacidade de especificar a marcação para a região MainContent.

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

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 ainda não contiver nenhum conteúdo, é mais fácil simplesmente 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 no Gerenciador de Soluções e escolha adicionar um novo Formulário Web chamado Default.aspx. Desta vez, marque a caixa de seleção "Selecionar página mestra" e escolha a página mestra site.mestre na lista.

Figura 5: Adicionar uma nova página Default.aspx escolhendo selecionar uma página mestra (clique para exibir a imagem em tamanho real)

Figura 6: Usar a Página Mestra Site.master

Observação

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 de 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. Retornaremos a ele mais adiante neste tutorial para adicionar conteúdo.

Observação

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

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

Com o ASP.NET site 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 modo 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 a Rede de Passaportes da Microsoft.
• Nenhum– nenhum modelo de autenticação é usado; todos os visitantes são anônimos.

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

Se o projeto ainda não contiver um arquivo Web.config, adicione um agora clicando com o botão direito do mouse no nome do projeto no Gerenciador de Soluções, escolhendo Adicionar Novo Item e adicionando um arquivo de Configuração da Web.

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

Em seguida, localize o elemento <authentication> e atualize-o para usar a autenticação de formulários. Após essa alteração, a marcação do arquivo Web.config deverá ser semelhante à 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>

Observação

Como Web.config é um arquivo XML, a diferenciação entre maiúsculas e minúsculas é importante. Certifique-se de definir o atributo de modo para Forms, começando com "F" maiúsculo. Se você usar uma caixa diferente, como "formulários", receberá um erro de configuração ao visitar o site por meio de um navegador.

Opcionalmente, o elemento <authentication> pode incluir um elemento <forms> 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. No próximo tutorial, exploraremos o elemento filho <forms> com mais detalhes.

Etapa 3: Criando a página de logon

Para dar 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", ele FormsAuthenticationModule redirecionará automaticamente o usuário para a página de logon se ele tentar acessar uma página que ele não está autorizado a exibir. Há também ASP.NET controles Web que exibirão um link para a página de logon para usuários anônimos. Isso levanta a questão: "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á fazer isso especificando-a em Web.config. Veremos como fazer isso no tutorial seguinte.

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

1. Forneça uma interface que permita que o visitante insira suas credenciais.
2. Determine se as credenciais enviadas são válidas.
3. Efetue o login do usuário criando o ticket de autenticação de formulários.

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

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

Figura 8: Adicionar uma nova página de ASP.NET chamada Login.aspx (clique para exibir a imagem em tamanho real)

A interface de página de logon típica consiste em duas caixas de texto – uma para o nome do usuário, uma para sua senha – e um botão para enviar o formulário. Os sites geralmente incluem uma caixa de seleção "Lembre-se de mim" que, se marcada, persiste o token de autenticação resultante nas reinicializações do navegador.

Adicione duas Caixas de Texto para Login.aspx e defina suas ID propriedades como Nome de Usuário e Senha, respectivamente. Também defina a propriedade TextMode de Password como Password. Em seguida, adicione um controle CheckBox, definindo sua ID propriedade como RememberMe e sua Text propriedade como "Remember Me". Depois disso, adicione um botão chamado LoginButton cuja Text propriedade está definida como "Logon". Por fim, adicione um controle de rótulo Web e defina sua ID propriedade como InvalidCredentialsMessage, sua Text propriedade como "Seu nome de usuário ou senha estão incorretos. Tente novamente: defina sua propriedade ForeColor para Red e sua propriedade Visible para False.

Neste ponto, sua tela deve ser semelhante à captura de tela na Figura 9 e a sintaxe declarativa da página deve ser semelhante à 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>

Figura 9: A página de logon contém duas Caixas de Texto, uma Caixa de Seleção, um Botão e um Rótulo (Clique para exibir a imagem em tamanho real)

Por fim, crie um manipulador de eventos para o evento Click do LoginButton. No Designer, basta clicar duas vezes no controle Botão 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 Clique do Botão– determinando se as credenciais fornecidas são válidas. Para fazer isso, precisa haver um repositório de usuários que contenha todas as credenciais dos usuários para que possamos determinar se as credenciais fornecidas correspondem a credenciais conhecidas.

Antes do ASP.NET 2.0, os desenvolvedores eram responsáveis por implementar seus próprios repositórios de usuários e escrever o código para validar as credenciais fornecidas no repositório. A maioria dos desenvolvedores implementaria o repositório de usuários em um banco de dados, criando uma tabela chamada Usuários com colunas como UserName, Password, Email, LastLoginDate e assim por diante. Essa tabela, então, teria um registro para cada conta de usuário. Verificar as credenciais fornecidas de um usuário envolveria a consulta do banco de dados para 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 repositório de usuários. Nesta série de tutoriais, usaremos o SqlMembershipProvider, que usa um banco de dados do SQL Server para o repositório de usuários. Ao usar o SqlMembershipProvider, precisamos implementar um esquema de banco de dados específico que inclua 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(nome de usuário, senha) da classe De associação, que retorna um valor booliano que indica se a validade da combinação de nome de usuário e senha. Como ainda não implementamos o repositório de usuários do SqlMembershipProvider, não é possível usar o método ValidateUser da classe De associação no momento.

Em vez de aproveitar o tempo para criar nossa própria tabela de banco de dados de usuários personalizado (que seria obsoleta depois que implementamos o SqlMembershipProvider), vamos codificar as credenciais válidas dentro da própria página de logon. No manipulador de eventos 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 ("senha"). O código percorre as matrizes de usuários e senhas em busca de uma correspondência válida entre nome de usuário e senha. Se o nome de usuário e a senha forem válidos, precisamos fazer logon no 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". Mas qual é a página apropriada? Lembre-se de que quando um usuário visita uma página que não está autorizado 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 tentasse visitar ProtectedPage.aspx e não estivesse autorizado a fazê-lo, o FormsAuthenticationModule os redirecionaria para:

Login.aspx? ReturnUrl=ProtectedPage.aspx

Após fazer logon com êxito, o usuário deverá ser redirecionado de volta para ProtectedPage.aspx. Como alternativa, os usuários podem visitar a página de logon por vontade própria. Nesse caso, depois que o usuário fizer logon, ele deve ser redirecionado para a página Default.aspx da pasta raiz.

Logar o usuário

Supondo que as credenciais fornecidas sejam válidas, precisamos criar um tíquete de autenticação de formulários, logando o usuário no site. A classe FormsAuthentication no namespace System.Web.Security oferece diversos métodos para fazer login e desconectar usuários por meio do sistema de autenticação de formulários. Embora existam vários métodos na classe FormsAuthentication, os três em que estamos interessados neste momento são:

• GetAuthCookie(username, persistCookie) – cria um tíquete de autenticação de formulários para o nome de usuário fornecido username. Em seguida, esse método cria e retorna um objeto HttpCookie que contém o conteúdo do tíquete de autenticação. Se persistCookie for verdadeiro, um cookie persistente é criado.
• SetAuthCookie(username, persistCookie) – chama o método GetAuthCookie(username, persistCookie) para gerar o cookie de autenticação de formulários. Em seguida, esse método adiciona o cookie retornado por GetAuthCookie à coleção Cookies (supondo que a autenticação de formulários baseados 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 Cookies. SetAuthCookie é útil se você quiser criar o ticket de autenticação de formulários e adicioná-lo ao conjunto 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 alguma página alternativa.

Como queremos logar o usuário e redirecioná-lo para a página apropriada, vamos usar RedirectFromLoginPage. Atualize o manipulador de eventos Click do LoginButton, substituindo as duas linhas TODO 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 do UserName TextBox para o parâmetro de 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 "Nope" e uma senha de "errado". Ao clicar no botão Login, ocorrerá um postback e o rótulo InvalidCredentialsMessage será exibido.

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

Em seguida, insira credenciais válidas e clique no botão Logon. Desta vez, quando ocorre o postback, um tíquete de autenticação de formulários é criado, e você é redirecionado automaticamente 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, bem como como identificar o usuário que está visitando a página.

A etapa 5 examina técnicas para desconectar 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 detecte 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 SSL (Secure Socket Layers). Isso garantirá que as credenciais (bem como a marcação HTML de toda a página) sejam criptografadas a partir do momento em que deixarem 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 seria enviada pelo fio em texto sem formatação. Você não precisa se preocupar em proteger o tíquete de autenticação de formulários, pois, por padrão, ele é criptografado e assinado digitalmente (para evitar adulteração). Uma discussão mais aprofundada sobre a segurança do ticket de autenticação de formulários é apresentada no tutorial a seguir.

Observação

Muitos sites financeiros e médicos são configurados para usar o 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: Detectar visitantes autenticados e determinar sua identidade

Neste ponto, habilitamos a autenticação de formulários e criamos uma página de logon rudimentar, mas ainda não examinamos como podemos determinar se um usuário é autenticado ou anônimo. Em determinados cenários, talvez queiramos 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 adicionar dois controles de painel, um chamado AuthenticatedMessagePanel e outro chamado AnonymousMessagePanel. Adicione um controle label chamado WelcomeBackMessage no primeiro Painel. No segundo Painel, adicione um controle HyperLink, defina sua propriedade Text como "Log In" e sua propriedade NavigateUrl como "~/Login.aspx". Neste ponto, a marcação declarativa para Default.aspx deve ser semelhante à 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ê provavelmente já adivinhou, a ideia aqui é exibir apenas o AuthenticatedMessagePanel para visitantes autenticados e apenas o AnonymousMessagePanel para visitantes anônimos. Para fazer isso, precisamos definir as propriedades visíveis desses painéis, dependendo se o usuário está conectado ou não.

A propriedade Request.IsAuthenticated retorna um valor booliano que indica se a solicitação foi autenticada. Insira o seguinte código no código do manipulador de eventos Page_Load:

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 não tenha feito logon, verá um link para a página de logon (consulte a Figura 11). Clique neste link e faça logon no site. Como vimos na Etapa 3, depois de inserir suas credenciais, você será retornado para Default.aspx, mas desta vez a página mostra a mensagem "Bem-vindo de volta!" (consulte a Figura 12).

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

Figura 12: Usuários autenticados veem a mensagem "Bem-vindos de volta!"

Podemos determinar a identidade do usuário conectado no momento por meio da propriedade User do objeto HttpContext. O objeto HttpContext representa informações sobre a solicitação atual e é a página inicial para 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 recebida, ele cria um novo objeto GenericPrincipal e o atribui à propriedade User.

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

• IsInRole(roleName) – um método que retorna um valor booleano que indica se o principal pertence à função especificada.
• Identidade – uma propriedade que retorna um objeto que implementa a interface IIdentity. A interface IIdentity define três propriedades: AuthenticationType, IsAuthenticated e Name.

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

string currentUsersName = User.Identity.Name;

Ao usar a autenticação de formulários, um objeto FormsIdentity é criado para a propriedade Identity do 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 por 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 Expiration, IsPersistent, IssueDate, Name e assim por diante.

O ponto importante a ser retirado 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 convertendo User.Identity para um objeto FormsIdentity e, em seguida, acessando a 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 Page_Load para que a propriedade Texto do Rótulo WelcomeBackMessage seja atribuída à cadeia de caracteres "Bem-vindo de volta, nome de usuário!"

WelcomeBackMessage.Text = "Bem-vindo de volta", + User.Identity.Name + "!";

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

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, ASP.NET inclui dois controles 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 Web baseado em modelo que facilita a exibição de dados diferentes para usuários autenticados e anônimos. O LoginView inclui dois modelos predefinidos:

• AnonymousTemplate – qualquer marcação adicionada a esse modelo só é exibida para visitantes anônimos.
• LoggedInTemplate – a marcação desse modelo é mostrada apenas 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, vamos adicionar um novo controle ContentPlaceHolder e colocar o controle LoginView nesse novo ContentPlaceHolder. A lógica dessa decisão se tornará evidente em breve.

Observação

Além do AnonymousTemplate e LoggedInTemplate, o controle LoginView pode incluir templates específicos de função. Modelos específicos de função mostram marcação somente para os usuários que pertencem a uma função especificada. Examinaremos as funcionalidades baseadas em função do controle LoginView em um próximo tutorial.

Comece adicionando um ContentPlaceHolder chamado LoginContent na página mestra dentro do elemento de navegação div. Você pode simplesmente arrastar um controle ContentPlaceHolder da Caixa de Ferramentas para a visão de origem, colocando o código resultante logo acima do "TODO: Menu irá para cá..." 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 ContentPlaceHolder LoginContent. O conteúdo colocado nos controles ContentPlaceHolder da página mestra é considerado conteúdo padrão para o ContentPlaceHolder. Ou seja, ASP.NET páginas que usam esta 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 Logon da Caixa de Ferramentas.

Figura 14: O controle LoginView na caixa de ferramentas

Em seguida, adicione dois <br/> elementos 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 à 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 do LoginView podem ser definidos a partir da interface de design ou da marcação declarativa. No Designer do Visual Studio, expanda a smart tag do LoginView, que lista os modelos configurados em um menu suspenso. 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 à 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 esta adição à página mestra Site.master, cada página em nossa página da web exibirá uma mensagem diferente, dependendo de o usuário estar autenticado. A Figura 15 mostra a página Default.aspx quando visitada por 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 de painel e lógica programática).

Figura 15: O controle LoginView exibe "Bem-vindo de volta, Jisun".

Como adicionamos o LoginView à página mestra, ele pode aparecer em todas as páginas do 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 login, pois um link para a página de login parece fora do lugar. Como colocamos o controle LoginView em um ContentPlaceHolder na página mestre, podemos sobrescrever 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 ContentPlaceHolder LoginContent 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 através do Designer, onde o ContentPlaceHolder LoginContent mostra a marcação padrão (o controle LoginView).

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

Para sobrescrever a marcação padrão do ContentPlaceHolder LoginContent, basta clicar com o botão direito do mouse na região no Designer e selecionar 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.

Observação

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 para o controle de conteúdo recém-criado. Se você estiver usando o Visual Studio 2008, depois de criar o novo controle de conteúdo, desmarque o conteúdo copiado da página mestra.

A Figura 17 mostra a página Login.aspx quando visitada de um navegador depois de fazer essa alteração. Observe que não há nenhuma mensagem "Olá, estranho" ou "Bem-vindo de volta, nome de usuário" no div< de navegação >à esquerda como há ao visitar Default.aspx.

Figura 17: A Página de Login oculta as marcações padrão do ContentPlaceHolder de login (clique para exibir a imagem em tamanho real)

Etapa 5: Fazer logoff

Na Etapa 3, analisamos a criação de uma página de login para entrar um usuário no site, mas ainda não vimos como fazer logoff de um usuário. Além dos métodos para fazer login de um usuário, a classe FormsAuthentication também fornece um método SignOut. O método SignOut simplesmente exclui o tíquete de autenticação de formulários, desconectando assim o usuário do site.

Oferecer um link de logout é um recurso tão comum que o ASP.NET inclui um controle especificamente projetado para fazer logoff de um usuário. O controle LoginStatus exibe um LinkButton "Login" ou um LinkButton "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. Os textos para os botões de link "Login" e "Logout" podem ser configurados por meio das propriedades LoginText e LogoutText do LoginStatus.

Clicar no LinkButton "Login" causa um postback, a partir do qual ocorre um redirecionamento para a página de login. Clicar no LinkButton "Logout" faz com que o controle LoginStatus invoque o método FormsAuthentication.SignOff e redirecione o usuário para uma página. A página à 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 estava apenas visitando. Se a página que eles estavam apenas 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 ocorre porque 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 autentica o usuário. Portanto, um redirecionamento explícito faz com que o navegador solicite novamente a página. Quando o navegador solicita novamente a página, o tíquete de autenticação de formulários foi removido e, portanto, a solicitação de entrada é anônima.

• Redirecionamento – o usuário é redirecionado para a URL especificada pela propriedade LogoutPageUrl do 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 Redirecionar para enviar o usuário para uma página que exibe uma mensagem confirmando que ele foi desconscrito. Comece criando uma página no diretório raiz chamada Logout.aspx. Não se esqueça de associar esta página à página mestre Site.master. Insira uma mensagem na marcação da página explicando ao usuário que ele foi desconectado.

Em seguida, volte à página mestre Site.master e adicione um controle LoginStatus logo abaixo do LoginView dentro do ContentPlaceHolder LoginContent. Defina a propriedade LogoutAction do controle LoginStatus como 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 usuários anônimos e autenticados, mas isso é OK porque o LoginStatus exibirá corretamente um LinkButton "Logoff" ou "Logout". Com a adição do controle LoginStatus, o HiperLink "Log In" no AnonymousTemplate é supérfluo, portanto, remova-o.

A Figura 18 mostra Default.aspx quando Jisun visita. Observe que a coluna esquerda exibe a mensagem "Bem-vindo de volta, Jisun", juntamente com um link para sair. Ao clicar no LinkButton, ocorre um postback, desconecta Jisun do sistema e, em seguida, ela é redirecionada para Logout.aspx. Como a Figura 19 mostra, quando Jisun chega 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.

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

Figura 19: Logout.aspx mostra "Bem-vindo, estranho" junto com um LinkButton "Logon" (clique para exibir a imagem em tamanho real)

Observação

Eu o encorajo a personalizar a página Logout.aspx para ocultar o LoginContent ContentPlaceHolder da página mestre (como fizemos para Login.aspx na Etapa 4). A razão é que o LinkButton "Login" renderizado pelo controle LoginStatus (aquele abaixo de "Olá, estranho") envia o usuário para a página de login, passando a URL atual no parâmetro de querystring ReturnUrl. Em suma, se um usuário que estava desconectado clicar no LinkButton "Login" do LoginStatus e, em seguida, fizer login, ele será redirecionado de volta para Logout.aspx, o que poderia facilmente confundir o usuário.

Resumo

Neste tutorial, começamos com um exame do fluxo de trabalho de autenticação de formulários e, em seguida, recorremos à implementação da 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 no 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 programático adicional para determinar se uma solicitação é autenticada e informações sobre a identidade do usuário. Há também os controles LoginView, LoginStatus e LoginName Web, que oferecem aos desenvolvedores uma maneira rápida e livre de código para executar muitas tarefas comuns relacionadas ao logon. Examinaremos esses e outros controles Web relacionados ao logon com mais detalhes em tutoriais futuros.

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

Divirta-se programando!

Leitura Adicional

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

• Alterações entre a segurança do IIS6 e do IIS7
• Controles de Login ASP.NET
• Segurança, associação e gerenciamento de funções profissional do ASP.NET 2.0 (ISBN: 978-0-7645-9698-8)
• O <authentication> elemento
• O elemento <forms> para <authentication>

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

• Usando a Autenticação de Formulários Básicos no ASP.NET

Sobre o autor

Scott Mitchell, autor de sete livros asp/ASP.NET e fundador da 4GuysFromRolla.com, trabalha com tecnologias da Microsoft Web desde 1998. Scott trabalha como consultor independente, treinador e escritor. Seu último livro é Sams Teach Yourself ASP.NET 2.0 em 24 Horas. Ele pode ser alcançado em mitchell@4GuysFromRolla.com.

Agradecimentos especiais a...

Esta série de tutoriais foi revisada por muitos revisores úteis. O revisor principal deste tutorial foi Esta série de tutoriais foi revisada por muitos revisores úteis. Os principais revisores deste tutorial incluem Alicja Maziarz, John Suru e Teresa Murphy. Interessado em revisar meus próximos artigos do MSDN? Se assim for, deixe-me uma linha em mitchell@4GuysFromRolla.com.

AnteriorPróximo