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 por ASP.NET Identity. É altamente recomendável atualizar os 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 uma série de vantagens em relação ao sistema de Associações do ASP.NET, incluindo:

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

Descarregar Código ou Descarregar PDF

Neste tutorial, passaremos da mera discussão à implementação; Em particular, analisaremos a implementação da autenticação de formulários. A aplicação Web que começamos a construir neste tutorial continuará a ser construída nos tutoriais subsequentes, à medida que passamos da autenticação de formulários simples para a 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, passaremos da mera discussão à implementação; Em particular, analisaremos a implementação da autenticação de formulários. A aplicação Web que começamos a construir neste tutorial continuará a ser construída nos tutoriais subsequentes, à medida que passamos da autenticação de formulários simples para a associação e funções.

Este tutorial começa com uma análise aprofundada do fluxo de trabalho de autenticação de formulários, um tópico que abordamos no tutorial anterior. Em seguida, criaremos um site ASP.NET através do qual demonstraremos os conceitos de autenticação de formulários. Em seguida, vamos configurar o site para usar autenticação de formulários, criar uma página de login simples e ver como determinar, em código, se um usuário está autenticado e, em caso afirmativo, o nome de usuário com o qual ele fez login.

Compreender 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 ofereça suporte a contas de usuário e autentique usuários por meio de uma página da Web. Por causa disso - e porque esses tutoriais se baseiam uns nos outros - eu encorajaria você a trabalhar neste tutorial na íntegra antes de passar para o próximo, mesmo que você já tenha tido 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 tempo de execução do ASP.NET processa uma solicitação para um recurso ASP.NET, como uma página de ASP.NET ou ASP.NET serviço Web, a solicitação gera vários eventos durante seu ciclo de vida. Há eventos levantados no início e no final da solicitação, aqueles levantados quando a solicitação está sendo autenticada e autorizada, um evento levantado no caso de uma exceção não tratada, 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. ASP.NET vem com vários módulos HTTP que executam tarefas essenciais nos bastidores. Dois módulos HTTP integrados que são especialmente relevantes para a nossa discussão são:

• FormsAuthenticationModule – autentica o utilizador inspecionando o bilhete de autenticação de formulários, que normalmente está incluído na coleção de cookies do utilizador. 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á ou não autorizado 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 os ACLs dos ficheiros solicitados.

A FormsAuthenticationModule tenta autenticar o utilizador antes de a UrlAuthorizationModule (e FileAuthorizationModule) executar. Se o usuário que faz 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 ao 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. Com a autenticação de formulários, no entanto, o status HTTP 401 Não autorizado nunca é enviado para o navegador porque o FormsAuthenticationModule deteta esse status e o modifica para redirecionar o usuário para a página de login (por meio de um status de Redirecionamento HTTP 302 ).

A responsabilidade da página de login é determinar se as credenciais do usuário são válidas e, em caso afirmativo, criar um tíquete de autenticação de formulários e redirecionar o usuário de volta para a página que estava tentando visitar. O bilhete de autenticação é incluído em solicitações subsequentes das 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 bilhete de autenticação durante as visitas à página

Após o login, 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. Isso geralmente é 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, uma vez que o ticket de autenticação de formulários tenha sido criado e armazenado nos cookies do navegador, cada visita subsequente a esse site envia o ticket de autenticação junto com a solicitação, identificando assim o usuário.

Um aspeto dos cookies é a sua validade, que é a data e 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 a partir 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 nas reinicializações do navegador para que não precise fazer login novamente cada vez que visitar o site. Esta decisão é muitas vezes tomada pelo usuário na forma de uma caixa de seleção "Lembrar-me" na página de login. Na Etapa 3, examinaremos como implementar uma caixa de seleção "Lembrar-me" na página de login. O tutorial a seguir aborda as configurações de expiração do bilhete de autenticação em detalhes.

Observação

É possível que o agente de utilizador utilizado para iniciar sessão no website não suporte cookies. Nesse caso, ASP.NET pode usar tíquetes de autenticação de formulários sem cookies. Nesse modo, o tíquete de autenticação é codificado na URL. Veremos quando os tíquetes de autenticação sem cookies 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 é o código gerenciado que faz parte do tempo de execução do ASP.NET. Antes da versão 7 do Internet Information Services (IIS), servidor web da Microsoft, havia uma barreira distinta entre o pipeline HTTP do IIS e o pipeline do tempo de execução do ASP.NET. Em resumo, no IIS 6 e anteriores, o FormsAuthenticationModule somente é executado quando uma solicitação é delegada do IIS para o tempo de execução do ASP.NET. Por padrão, o IIS processa o próprio conteúdo estático – como páginas HTML, CSS e arquivos de imagem – e só envia solicitações para o tempo de execução do ASP.NET quando uma página com uma extensão de .aspx, .asmx ou .ashx é solicitada.

O IIS 7, no entanto, permite a integração dos pipelines de IIS e 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 Alterações entre a segurança do IIS6 e do IIS7, Segurança da plataforma Web e Noções básicas sobre a 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 recursos manipulados pelo tempo de execução ASP.NET. Da mesma forma, as regras de autorização de URL só são aplicadas aos recursos manipulados pelo tempo de execução do ASP.NET. Mas com o IIS 7 é possível integrar o FormsAuthenticationModule e o UrlAuthorizationModule no 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

A fim de alcançar o maior público possível, o site ASP.NET que estaremos construindo 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 do SqlMembershipProvider usuário 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 do 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 um download. Este aplicativo para download foi criado com o Visual Web Developer 2008 destinado ao .NET Framework versão 3.5. Como o aplicativo é direcionado para o .NET 3.5, seu arquivo de Web.config inclui elementos de configuração adicionais específicos do 3.5. Resumindo, se você ainda não instalou o .NET 3.5 no seu computador, o aplicativo Web para download não funcionará sem primeiro remover a marcação específica do 3.5 do Web.config.

Antes de podermos configurar a autenticação de formulários, precisamos primeiro de um site ASP.NET. Comece criando um novo site 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. Escolha o modelo ASP.NET Web Site, defina a lista pendente Localização como Sistema de Ficheiros, escolha uma pasta para colocar o Web 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 oferece suporte a dois modos de gerenciamento de projetos: Projetos de Site e Projetos de Aplicativo Web. Projetos de Web Site não possuem um arquivo de projeto, enquanto 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 oferecia suporte apenas a projetos de sites, 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. As edições do Visual Web Developer 2005 e 2008, no entanto, suportam apenas projetos de Web Site. Utilizarei o modelo Web Site Project. Se você estiver usando uma edição não Express e quiser usar o modelo de Projeto de Aplicativo Web , sinta-se à vontade para fazê-lo, mas esteja ciente de que pode haver algumas discrepâncias entre o que você vê na tela e as etapas que você deve seguir em comparação com as capturas de tela mostradas e as instruções fornecidas nestes tutoriais.

Figura 2: Criar um novo ficheiro do site System-Based (Clique para visualizar 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. Master pages permitem que um desenvolvedor de páginas defina um modelo comum para 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 assim a atualização ou o ajuste do layout do site.

Figura 3: Adicionar uma página mestra chamada Site.master ao site (Clique para visualizar a imagem em tamanho real)

Defina o layout de página em todo o site aqui na página mestra. Você pode usar o modo Design e adicionar qualquer controle de layout ou da Web que precisar, ou pode adicionar a marcação manualmente no modo Código-fonte. Estruturei o layout da minha página mestra para imitar o layout usado na minha série de tutoriais Trabalhando com dados na ASP.NET 2.0 (veja a Figura 4). A página mestra usa folhas de estilo em cascata para posições e estilos com as configurações CSS definidas no arquivo Style.css (que está incluído no download associado deste tutorial). Embora você não possa distinguir a partir da marcação mostrada abaixo, as regras CSS são definidas de modo que o conteúdo do div< de navegação >é absolutamente posicionado de modo que ele aparece à esquerda e tem 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 ASP.NET páginas que usam a página mestra. Essas regiões de conteúdo editável 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, mudar para a vista Design mostra o layout da página principal. 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.

Figura 4: A página mestra, quando visualizada através da visualização Design (Clique para visualizar a imagem em tamanho real)

Criação de páginas de conteúdo

Neste momento, 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 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 na lista.

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

Figura 6: Utilize 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 incluirá 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 "Web Content Form" e clicar em Add, o Visual Studio exibirá a mesma caixa de diálogo Select a Master mostrada na Figura 6.

A marcação declarativa da nova página Default.aspx inclui apenas uma diretiva @Page que especifica o caminho para o arquivo da página mestra e um controlo de conteúdo para o ContentPlaceHolder MainContent 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 adiante neste tutorial para adicionar conteúdo.

Observação

Nossa página mestra inclui uma seção para um menu ou alguma outra interface de navegação. Vamos criar 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 mode que especifica o modelo de autenticação usado pelo aplicativo. Este atributo pode ter um dos seguintes quatro valores:

• Windows – como 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 utilizadores são autenticados através de um formulário numa página Web.
• Passport – os usuários são autenticados usando o Passport Network 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 atributo mode do elemento <authentication> para Forms.

Se o seu projeto ainda não contém 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 seu projeto ainda não incluir Web.config, adicione-o agora (Clique para visualizar a imagem em tamanho real)

Em seguida, localize o elemento e atualize-o para usar a <authentication> autenticação de formulários. Após essa alteração, a marcação do arquivo Web.config deve 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, o invólucro é importante. Certifique-se de definir o atributo mode como Forms, com um "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 <authentication> elemento pode incluir um <forms> elemento filho que contenha 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 com mais detalhes no próximo tutorial.

Etapa 3: Criando a página de login

Para suportar a autenticação de formulários, o nosso site precisa de uma página de login. 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 login se ele tentar acessar uma página que não está autorizado a visualizar. Há também ASP.NET controles da Web que exibirão um link para a página de login para usuários anônimos. Isso levanta a questão: "Qual é o URL da página de login?"

Por padrão, o sistema de autenticação de formulários espera que a página de login seja nomeada Login.aspx e colocada no diretório raiz do aplicativo Web. Se pretender utilizar um URL de página de início de sessão diferente, pode fazê-lo especificando-o em Web.config. Veremos como fazer isso no tutorial subsequente.

A página de login 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. Inicie sessão do utilizador criando o bilhete de autenticação de formulários.

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

Vamos começar com a primeira tarefa. Adicione uma nova página de 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 visualizar a imagem em tamanho real)

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

Adicione duas TextBoxes ao Login.aspx e defina suas ID propriedades como UserName e Password, 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 Button chamado LoginButton cuja Text propriedade está definida como "Login". E, finalmente, adicione um controle Web Label e defina sua ID propriedade como InvalidCredentialsMessage, sua Text propriedade como "Seu nome de usuário ou senha é inválido. Por favor, tente novamente.", altere a sua propriedade ForeColor para Vermelho, e a sua propriedade Visible para Falso.

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 login contém duas caixas de texto, uma caixa de seleção, um botão e um rótulo (Clique para visualizar a imagem em tamanho real)

Finalmente, crie um manipulador de eventos para o evento Click 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 Button's Click – 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 quaisquer credenciais conhecidas.

Antes do ASP.NET 2.0, os desenvolvedores eram responsáveis por implementar os seus próprios repositórios de utilizadores e escrever o código para validar as credenciais fornecidas contra o repositório. A maioria dos desenvolvedores implementaria o armazenamento do usuário em um banco de dados, criando uma tabela chamada Usuários com colunas como UserName, Password, Email, LastLoginDate e assim por diante. Então, esta tabela teria um registo por conta de utilizador. A verificação das credenciais fornecidas por um usuário envolveria consultar o banco de dados em busca de 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 do usuário. Nesta série de tutoriais, usaremos o SqlMembershipProvider, que usa um banco de dados SQL Server para o repositório do usuário. 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(username, password) da classe Membership, que retorna um valor booleano indicando se a validade da combinação de nome de usuário e senha. Como ainda não implementamos o repositório de usuário do SqlMembershipProvider, não podemos usar o método ValidateUser da classe Membership no momento.

Em vez de dedicar um tempo para criar nossa própria tabela de banco de dados de Usuários personalizada (que seria obsoleta quando implementássemos o SqlMembershipProvider), vamos codificar as credenciais válidas dentro da própria página de login. No manipulador de eventos Click 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, existem 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 procurando uma correspondência válida de nome de usuário e senha. Se o nome de usuário e a senha forem válidos, precisamos fazer login no usuário e, em seguida, redirecioná-lo 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 visualizar, o FormsAuthenticationModule o redireciona automaticamente para a página de login. 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 o redirecionaria para:

Login.aspx? ReturnUrl=ProtectedPage.aspx

Após o login bem-sucedido, o usuário deve ser redirecionado de volta para ProtectedPage.aspx. Em alternativa, os utilizadores podem visitar a página de início de sessão por sua própria vontade. Nesse caso, depois de fazer login no usuário, eles devem ser enviados para a página de Default.aspx da pasta raiz.

Efetuando login no usuário

Supondo que as credenciais fornecidas sejam válidas, precisamos criar um tíquete de autenticação de formulários, fazendo login do usuário no site. A classe FormsAuthentication no namespace System.Web.Security fornece métodos variados para fazer login e logout de 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. 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, então 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 por GetAuthCookie à coleção Cookies (assumindo que a autenticação de formulários baseada em cookies está sendo usada; caso contrário, esse método chama uma classe interna que lida com a lógica de tíquete sem cookie).
• RedirectFromLoginPage(username, persistCookie) – este método chama SetAuthCookie(username, persistCookie) e, em seguida, redireciona o usuário para a página apropriada.

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

Como queremos fazer login no 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 username do tíquete de autenticação de formulários e o estado verificado do CheckBox RememberMe para o parâmetro persistCookie .

Para testar a página de login, visite-a em um navegador. Comece inserindo credenciais inválidas, como um nome de usuário de "Não" 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 visualizar a imagem em tamanho real)

Em seguida, insira credenciais válidas e clique no botão Login. Desta vez, quando o postback ocorre, um tíquete de autenticação de formulários é criado e o utilizador é automaticamente redirecionado de volta para o Default.aspx. Neste ponto, você fez login no site, embora não haja pistas visuais 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 identificar o usuário que visita a página.

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

Protegendo a página de login

Quando o utilizador introduz as suas credenciais e submete o formulário da página de início de sessão, as credenciais – incluindo a sua palavra-passe – são transmitidas através da Internet para o servidor Web em texto simples. Isso significa que qualquer hacker que farejar o tráfego da rede pode ver o nome de utilizador e a senha. Para evitar isso, é essencial criptografar o tráfego de rede usando Secure Socket Layers (SSL). Isso garantirá que as credenciais (bem como a marcação HTML de toda a página) sejam criptografadas desde o momento em que saem do navegador até serem recebidas pelo servidor web.

A menos que seu site contenha informações confidenciais, você só precisará usar SSL na página de login e em outras páginas onde a senha do usuário seria enviada por fio em texto simples. 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 evitar adulteração). Uma discussão mais aprofundada sobre a segurança do bilhete de autenticação de formulários é abordada no tutorial a seguir.

Observação

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 esse site, 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: Detetando visitantes autenticados e determinando sua identidade

Neste ponto, habilitamos a autenticação de formulários e criamos uma página de login rudimentar, mas ainda não examinamos como podemos determinar se um usuário é autenticado ou anônimo. Em certos cenários, podemos querer 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 de Default.aspx existente para ilustrar essas técnicas. No Default.aspx adicione dois controles Panel, 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 booleano 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 este código em vigor, visite Default.aspx através de um navegador. Supondo que você ainda não tenha feito login, você verá um link para a página de login (veja a Figura 11). Clique neste link e faça login no site. Como vimos na Etapa 3, depois de inserir suas credenciais, você retornará ao Default.aspx, mas desta vez a página mostra a mensagem "Bem-vindo de volta!" (veja a Figura 12).

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

Figura 12: Usuários autenticados recebem a mensagem "Bem-vindo de volta!" Mensagem

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 casa de objetos ASP.NET comuns como Response, Request e Session, 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 bilhete 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:

• IsInRole(roleName) – um método que retorna um valor booleano indicando se o principal pertence à função especificada.
• Identity – 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:

// Nome do usuário atual 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 do utilizador 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 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 transmitindo 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 Text do rótulo WelcomeBackMessage receba a 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 login 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

A exibição de conteúdo diferente para utilizadores autenticados e anónimos é um requisito comum; assim como exibir o nome do utilizador atualmente conectado. Por esse motivo, 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 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 este modelo só é exibida para visitantes anônimos.
• LoggedInTemplate – a marcação deste 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, porém, vamos adicionar um novo controle ContentPlaceHolder e, em seguida, colocar o controle LoginView dentro desse novo ContentPlaceHolder. A fundamentação desta decisão tornar-se-á evidente em breve.

Observação

Além de AnonymousTemplate e LoggedInTemplate, o controle LoginView pode incluir modelos específicos da função. Os modelos específicos da função mostram a marcação apenas 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 por adicionar um ContentPlaceHolder denominado LoginContent na página mestra dentro do elemento <div> de navegação. Você pode simplesmente arrastar um controle ContentPlaceHolder da Caixa de Ferramentas para a visualização de origem, colocando a marcação resultante logo acima do "TODO: Menu irá 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, ASP.NET páginas 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 login estão localizados na guia Login 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 ter a seguinte aparência:

<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 do Designer ou da marcação declarativa. No Editor do Visual Studio, expanda o tag inteligente do LoginView, que lista os templates configurados numa lista pendente. 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 digite 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 seu 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 nosso site exibirá uma mensagem diferente, dependendo se o usuário está autenticado. A Figura 15 mostra a página Default.aspx quando visitada através 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 (através do controle LoginView que acabamos de adicionar) e uma vez na área de conteúdo do Default.aspx (via 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 onde 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 de lugar ali. Como colocamos o controlo LoginView num ContentPlaceHolder na página mestra, podemos substituir essa marcação padrão na nossa página de conteúdo. Abra Login.aspx e vá para o Designer. Como não definimos explicitamente um controle Content em Login.aspx para o LoginContent ContentPlaceHolder na página mestra, a página de login mostrará a marcação padrão da página mestra para esse ContentPlaceHolder. Você pode ver isso através do Designer – o LoginContent ContentPlaceHolder mostra a marcação padrão (o controle LoginView).

Figura 16: A página de login mostra o conteúdo padrão para o LoginContent ContentPlaceHolder da página mestra (Clique para visualizar a imagem em tamanho real)

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, assim, nos permite definir conteúdo personalizado para essa página. Você pode adicionar uma mensagem personalizada aqui, como "Por favor, faça login...", 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 Content recém-criado. Se você estiver usando o Visual Studio 2008, então, 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 a partir 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 >esquerdo como há ao visitar Default.aspx.

Figura 17: A página de login oculta a marcação padrão do LoginContent ContentPlaceHolder (Clique para visualizar a imagem em tamanho real)

Passo 5: Terminar sessão

Na Etapa 3, analisamos a criação de uma página de login para fazer login de um usuário no site, mas ainda não vimos como fazer logout de um usuário. Além dos métodos para registrar um usuário, a classe FormsAuthentication também fornece um método SignOut. O método SignOut simplesmente elimina o bilhete de autenticação de formulários, fazendo o logout do utilizador do site.

Oferecer um link de logout é um recurso tão comum que ASP.NET inclui um controle projetado especificamente para fazer logout 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 "Login" LinkButton é renderizado para usuários anônimos, enquanto um "Logout" LinkButton é exibido para usuários autenticados. O texto para os LinkButtons "Login" e "Logout" pode ser configurado através das propriedades LoginText e LogoutText do LoginStatus.

Clicar no "LinkButton" de "Login" causa um postback, a partir do qual é realizado um redirecionamento para a página de login. Clicar no "Logout" LinkButton faz com que o controle LoginStatus invoque o método FormsAuthentication.SignOff 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:

• Refresh – o padrão; redireciona o usuário para a página que ele 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 login.

Você pode estar curioso para saber por que um redirecionamento é realizado aqui. Se o usuário quer permanecer na mesma página, por que a necessidade do redirecionamento explícito? O motivo é que, quando o LinkButton "Logoff" é clicado, o utilizador ainda tem o tíquete de autenticação de formulários no seu conjunto de cookies. Consequentemente, o pedido de postback é um pedido autenticado. 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 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 login.

Vamos adicionar um controle LoginStatus à página mestra e configurá-lo para usar a opção Redirecionar para enviar o usuário a uma página que exibe uma mensagem confirmando que ele foi desconectado. Comece criando uma página no diretório raiz chamada Logout.aspx. Não se esqueça de associar esta página à página mestra Site.master. Em seguida, insira uma mensagem na marcação da página explicando ao usuário que ele foi desconectado.

Em seguida, retorne à página mestra Site.master e adicione um controle LoginStatus abaixo de LoginView no LoginContent ContentPlaceHolder. Defina a propriedade LogoutAction do controle LoginStatus como Redirect 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 aparecerá para usuários anônimos e autenticados, mas tudo bem porque o LoginStatus exibirá corretamente um LinkButton "Login" ou "Logout". Com a adição do controle LoginStatus, o HyperLink "Login" no AnonymousTemplate é supérfluo, portanto, remova-o.

A Figura 18 mostra Default.aspx quando Jisun visita. Observe que a coluna da esquerda exibe a mensagem "Bem-vindo de volta, Jisun" junto com um link para sair. Clicar no LinkButton de logout causa um postback, remove Jisun do sistema e, em seguida, redireciona-a para Logout.aspx. Como mostra a Figura 19, quando Jisun chega ao Logout.aspx ela já foi desconectada e, portanto, é anônima. Consequentemente, a coluna da esquerda mostra o texto "Bem-vindo, estranho" e um link para a página de login.

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

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

Observação

Eu encorajo você a personalizar a página Logout.aspx para ocultar o LoginContent ContentPlaceHolder da página mestra (como fizemos para Login.aspx na Etapa 4). O motivo é porque 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 querystring ReturnUrl. Em resumo, se um utilizador que fez logout clicar no LinkButton "Login" deste LoginStatus e, em seguida, fizer login, será redirecionado novamente para Logout.aspx, o que pode facilmente confundir o utilizador.

Resumo

Neste tutorial, começamos com um exame do fluxo de trabalho de autenticação de formulários e, em seguida, passamos para a 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 em seu tíquete de autenticação de formulários e redirecionar usuários não autorizados para a página de login.

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 da Web LoginView, LoginStatus e LoginName, que oferecem aos desenvolvedores uma maneira rápida e livre de código para executar muitas tarefas comuns relacionadas ao login. Examinaremos esses e outros controles da Web relacionados ao login 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, examinamos como os tíquetes de autenticação de formulários sem cookies funcionam ou exploramos como ASP.NET protege o conteúdo do tíquete de autenticação de formulários.

Feliz Programação!

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
• Login ASP.NET Controles
• Professional ASP.NET 2.0 Segurança, associação e gerenciamento de funções (ISBN: 978-0-7645-9698-8)
• O elemento <authentication>
• O <forms> elemento para <authentication>

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

• Usando a autenticação básica de formulários no ASP.NET

Sobre o Autor

Scott Mitchell, autor de sete livros sobre ASP/ASP.NET e fundador da 4GuysFromRolla.com, trabalha com tecnologias Web da Microsoft desde 1998. Scott trabalha como consultor, formador e escritor independente. Seu último livro é Sams Teach Yourself ASP.NET 2.0 in 24 Hours. Ele pode ser contatado em mitchell@4GuysFromRolla.com.

Um agradecimento especial a...

Esta série de tutoriais foi revisada por muitos revisores úteis. O revisor principal para este 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 rever meus próximos artigos do MSDN? Se for o caso, envie-me uma mensagem para mitchell@4GuysFromRolla.com.

AnteriorPróximo