As Roles ou papéis em português nos ajudam a gerenciar as autorizações que um determinado usuário tem dentro de uma aplicação. Essas roles nos permitem customizar o acesso a recursos da aplicação ou até mesmo da página. Imaginem a seguinte situação: você tem em sua intranet uma aplicação onde os usuários se autenticam e têm acesso à aplicação ASP.NET. Dentro desta aplicação existe uma página ASPX que lista os registros de uma determinada tabela da base de dados, mas somente quem é “Administrador” pode excluir informações desta tabela. Mas podemos ir além disso, ou seja, podemos até mesmo especificar que usuários não contidos na role “Administrador” não consigam abrir a página ExtratoPagamentos.aspx.

Com o uso de roles você consegue definir regras para isso, ou seja, você pode criar suas próprias regras durante o desenvolvimento, onde você pode dizer que somente usuários que estão contidos na role “Administrador” podem clicar no botão de exclusão do registro. Obviamente que somente depois de devidamente autenticado o usuário tem acesso a aplicação, já que roles não trabalham com usuários anônimos. Cada usuário pode estar contido em uma ou muitas roles, dando assim uma maior flexibilidade.

A organização de roles na aplicação ajuda bastante a definir a arquitetura da segurança da mesma, mas há também um diagrama na UML, chamado de Use Cases, onde é possível extrairmos possível usuários e roles que a aplicação poderá vir a ter. Como já notamos a importância disso, a Microsoft implementou (assim como o Membership) o modelo de Provider Model em sua arquitetura e, com isso, nos disponibilizou o que chamamos de Role Management API. Esta API não está restrita a trabalharmos com páginas ou diretórios, mas a mesma fornece uma série de métodos para que, programaticamente, consigamos ajustar alguns recursos a roles específicas.

Para aqueles que já estão familiarizados com a arquitetura do Windows, verão uma grande semelhança entre as roles e os grupos de usuários do Windows. Já que utilizamos a arquitetura de Provider Models, a API pode ser tanto utilizada com a classe SqlRoleProvider quanto para a classe WindowsTokenRoleProvider. A primeira delas usa o SQL Server para o armazenamento das roles dos usuários. Já a segunda utiliza os grupos do Windows para trabalhar, mas lembrando que só é interessante o seu uso se for em uma intranet, pois o uso dela em uma aplicação que será vista por toda a internet é completamente inviável. Já para internet, devemos utilizar o FormsAuthentication para estarmos gerenciando os usuários dentro da aplicação e a API de Roles está completamente integrada com isso. Assim como no Membership, utilizaremos aqui a classe SqlRoleProvider (que usa um banco de dados dentro do SQL Server) para os exemplos de uso e configurações.

A configuração no arquivo Web.Config

A forma de configuração do Role Provider é bem parecida com a do Membership, pois temos que especificar todas as configurações que desejarmos para a API no arquivo Web.Config através do elemento roleManager. Este elemento também possui um elemento filho chamado providers, o qual recebe uma coleção dos providers que podem ser utilizados pela aplicação. Através da tabela abaixo analisaremos atributo por atributo destas configurações e para o que cada um deles serve:

Agora que já conhecemos todos os parâmetros possíveis dos elementos acima, veremos abaixo um exemplo de como estar configurando isso dentro do arquivo Web.Config da aplicação ASP.NET:

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <clear/>
    <add 
      name="SqlConnectionString"
      connectionString="Data Source=local;Initial Catalog=DBTest;Integrated Security=True;"/>
  </connectionStrings>
  <system.web>
    <roleManager defaultProvider="SqlRoleProvider" 
        enabled="true"
        cacheRolesInCookie="true"
        cookieName=".ASPROLES"
        cookieTimeout="30"
        cookiePath="/"
        cookieRequireSSL="false"
        cookieSlidingExpiration="true"
        cookieProtection="All" >
        <providers>
          <add
            name="SqlRoleProvider"
            type="System.Web.Security.SqlRoleProvider"
            connectionStringName="SqlConnectionString" 
            applicationName="NomeAplicacao" />            
        </providers>
    </roleManager>
  </system.web>
</configuration>

A classe Roles

A classe estática Roles, encontrada dentro do Namespace System.Web.Security, é usada pelo ASP.NET para criar e gerenciar as roles. Esta classe faz uso da classe FormsAuthentication (já existente nas versões anteriores do ASP.NET) para criar e gerenciar a autorização do usuário dentro da aplicação Web.

Falando um pouco sobre o seu funcionamento: existe um membro interno chamado s_Provider do tipo RoleProvider (a classe base para as classes concretas de RoleProvider, como por exemplo o SqlRoleProvider), o qual receberá a instância da classe concreta. Essa inicialização acontece quando um método interno chamado Initialize é executado. Ele se encarrega de extrair os providers do arquivo Web.Config e instancia-los para que, quando chamarmos os métodos e propriedades, já sejam efetivamente os métodos e propriedades da classe concreta que queremos utilizar. Indo um pouco mais abaixo, existe uma classe (também dentro do Namespace System.Web.Security) chamada RolePrincipal. Essa classe implementa a interface IPrincipal e representa o contexto de segurança da requisição HTTP corrente. Quando as roles estão habilitadas na aplicação, o módulo RoleManagerModule define a propriedade User da classe HttpContext da requisição corrente, com uma instância da classe RolePrincipal.

A classe RolePrincipal expõe as identidades de segurança da requisição HTTP e se encarrega de executar as checagens de roles. Se a propriedade CacheRolesInCookie estiver definida como True, a RolePrincipal tenta recuperar as roles que estão armazenadas em um cookie. Já, se esta opção estiver definida como False, a classe RolePrincipal recupera as roles do usuário através do provider especificado no arquivo Web.Config.

Como esta classe encapsula o acesso ao provider específico, ela fornece facilidades como: criação de novas roles, verificação de usuários, gerenciamento de roles em seu repositório (SQL Server, Grupos do Windows, etc). Como já vimos anteriormente o funcionamento interno desta classe, podemos perceber que o ASP.NET confia no provider especificado no Web.Config para se comunicar com a fonte de dados. Como já sabemos, o .NET Framework inclui a classe SqlRoleProvider para acesso e persistência dos dados no SQL Server e é este que vamos utilizar no decorrer dos exemplos deste artigo.

Mas esta arquitetura é extensível, ou seja, a qualquer momento eu posso criar o meu próprio provider de Roles, onde eu queira customizá-lo para um outro repositório qualquer. E, para que isso seja possível, é necessário herdarmos da classe abstrata chamada RoleProvider e customizá-la de acordo com o nosso repositório. Para ilustar o cenário, imaginemos que desejamos ter um provider de RoleProvider sendo persistido em um arquivo XML:

public class XmlRoleProvider : RoleProvider
{
    // customizo aqui todos os métodos e
    // propriedades necessárias
}

Não vou me preocupar aqui em mostrar e explicar as propriedades da classe Roles justamente porque são propriedades de somente leitura e apenas devolvem os valores que configuramos no Web.Config para o provider. Nos concentraremos apenas nos métodos, pois é o mais importante, os quais nos dão todas as funcionalidades de manutenção e criação de roles na base de dados.

Depois da teoria, veremos abaixo um trecho curto de código que mostra como chamar esses métodos e propriedades via código:

// Criando Role
if(!Roles.RoleExists("Administradores"))
{
    Roles.CreateRole("Administradores");
}

// Definindo Usuário para uma Role
if(!Roles.IsUserInRole("IsraelAece", "Administradores"))
{
    Roles.AddUserToRole("IsraelAece", "Administradores");
}

// Recuperando Roles de um Usuário
string[] roles = Roles.GetRolesForUser("IsraelAece");
foreach(string role in roles)
{
    Response.Write(string.Format("Role: {0}<br>", role));
}

// Excluindo Usuário da Role
if(Roles.Delete("Administradores", false))
{
    Response.Write("Role excluída com sucesso.");
}

// Habilitando Recursos
this.btnLiberarCredito.Visible = Roles.IsUserInRole("Administradores");

Além disso, ainda temos alguns outros lugares (não menos importantes) para utilizarmos as roles; um deles é no arquivo Web.Config. É nele que definimos páginas ou diretórios da aplicação que são restritas à determinadas roles. Vale lembrar que também é permitido termos vários arquivos Web.Config’s nas pastas internas onde, para cada uma, implementamos um arquivo de configuração definindo as roles, podendo sobrescrever as roles especificadas no arquivo Web.Config da raiz.

Para exemplificar o uso das roles no arquivo Web.Config, analise o código abaixo:

<?xml version="1.0" encoding="utf-8" ?> 
<configuration> 
  <location path="ExtratoConta.aspx"> 
    <system.web> 
      <authorization> 
        <deny users="?" />
        <allow roles="*" />
      </authorization> 
    </system.web> 
  </location>
  <location path="DarCredito.aspx"> 
    <system.web> 
      <authorization> 
        <deny users="?" />
        <allow roles="Gerentes, Administradores" />
      </authorization> 
    </system.web> 
  </location> 
</configuration>

Nas especificações acima a página ExtratoConta.aspx está proibida para usuários anônimos (não autenticados) e permitida para todos os usuários autenticados (independentemente da role). Já a página DarCredito.aspx está proibida para usuários anônimos e permitida somente para usuários que estão contidos dentro da role “Gerentes” ou “Administradores”.

Mas o uso ainda não pára por aí. O ASP.NET 2.0 fornece um arquivo chamado Web.sitemap. Este arquivo, que em sua estrutura é um XML, tem a finalidade de carregar controles hierárquicos, como por exemplo: Menu, TreeView, SiteMapPath (controles contidos na Tab Navigation) da ToolBox do Visual Studio .NET 2005. Este arquivo é responsável por toda a navegação da aplicação e no elemento siteMapNode existe um atributo chamado roles, onde passamos as roles em que o usuário autenticado deve estar contido. Se não estiver, o item não chega à ser exibido para o usuário. Abaixo é mostrado um exemplo de um arquivo Web.sitemap com estas configurações:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0">
  <siteMapNode url="Default.aspx" title="Home">    
    <siteMapNode url="" title="ContaCorrente" title="Conta Corrente">
      <siteMapNode url="ExtratoConta.aspx" title="Extrato" />
      <siteMapNode url="DarCredito.aspx" title="Crédito" roles="Gerentes, Administradores" />
    </siteMapNode>
  </siteMapNode>
</siteMap>

A onda do momento é o Framework Atlas para processamento de códigos server-side, sem a necessidade da reconstrução completa da página. Isso torna a aplicação Web muito parecida com aplicações Windows, deixando-a muito mais interativa.

Devido a isso, nas últimas versões do Atlas (ainda em versões não Release), a Microsoft implementou métodos dentro de um determinado objeto para trabalhar diretamente com a API de Membership, sem a necessidade de um refresh e a reconstrução da página toda. O objeto que disponibiliza estes serviços chama-se Sys.Services.AuthenticationService e é um objeto desenvolvido em Javascript. Este, por sua vez, têm três métodos, os quais analisaremos as suas utilidades na tabela abaixo:

Quando adicionamos um projeto ASP.NET Atlas no Visual Studio .NET 2005, a autenticação via Altas vem desabilitada no Web.Config e é necessário habilitarmos para fazer o uso do objeto de autenticação. Para se certificar disso, é necessário que o arquivo Web.Config da aplicação ASP.NET Atlas contenha as seguintes entradas:

<sectionGroup 
    name="microsoft.web" 
    type="Microsoft.Web.Configuration.MicrosoftWebSectionGroup">
    <!-- outras seções -->
    <section 
	name="webServices" 
	type="Microsoft.Web.Configuration.WebServicesSection" 
	requirePermission="false" />
    <section 
	name="authenticationService" 
	type="Microsoft.Web.Configuration.AuthenticationServiceSection" 
	requirePermission="false" />
</sectionGroup>

<!-- 
    
    Certifique-se de que o Provider padrão esteja configurado
    corretamente e apontando para uma base de dados válida.

    As seções de configurações de SqlMembershipProvider
    foram suprimidas para poupar espaço, mas não muda nada
    em relação aos exemplos anteriores.
    
-->

<webServices enableBrowserAccess="true" />
<authenticationService enabled="true" />

Notem que há um elemento chamado webServices que neste cenário, é responsável por efetuar a autenticação. Na página que fará a autenticação via Atlas você notará que não se tem código em VB.NET ou C#, tudo será escrito utilizando Javascript. Acredito que, como já aconteceu com alguns controles, nas próximas versões isso já esteja encapsulado em controles drag-and-drop. Para iniciarmos o entendimento da estrutura cliente, a página irá conter um controle do tipo ScriptManager, o qual tem a finalidade de expor (código cliente) grande parte das funcionalidades e controles do Atlas.

É através do controle ScriptManager que temos acesso ao objeto Sys.Services.AuthenticationService. Agora que já temos acesso à ele, resta codificar para efetuarmos o login do usuário. Como qualquer outro sistema de Login, é necessário termos dois controles TextBox e um Button. Teremos também Label para exibirmos a mensagem de autenticado/não autenticado para o usuário saber se foi ou não autenticado com sucesso. O código é mostrado abaixo:

<html xmlns="http://www.w3.org/1999/xhtml">
    <head id="Head1" runat="server">
        <atlas:ScriptManager 
            ID="scriptManager" 
            runat="server" 
            EnableScriptComponents="false" >
        </atlas:ScriptManager>
    </head>
<body>
    <form id="form1" runat="server">
        <span id="TextoLogado" 
            style="visibility:hidden;color:Green" 
            visible="false">
            <b>Logado.</b>
        </span> 
        <span 
            id="TextoNaoLogado" 
            style="visibility:visible;color:Red">
            <b>Não logado.</b>
        </span>
        <br /><br />        
        
        Login: <input type="text" id="txtLogin" />
        <br />
        Senha: <input type="password" id="txtSenha" />
        <br /><br />
        <button id="btnEnviar" onclick="OnSubmitLogin()">Efetuar Login</button>

        
            var login = document.getElementById('txtLogin');
            var senha = document.getElementById('txtSenha');
            var lblLogado = document.getElementById('TextoLogado');
            var lblNaoLogado = document.getElementById('TextoNaoLogado');
            var buttonLoginLogout = document.getElementById('btnEnviar');            
                
            function OnSubmitLogin() { 
                Sys.Services.AuthenticationService.login(
                    login.value, 
                    senha.value, 
                    false, 
                    OnLoginComplete); 
                    
                return false;
            }
            
            function OnLoginComplete(result) {                
                senha.value = '';
                if (result) {
                    login.value = '';
                    lblLogado.style.visibility = "visible";
                    lblNaoLogado.style.visibility = "hidden";  
                   
                    buttonLoginLogout.innerText = "Efetuar Logout";         
                    buttonLoginLogout.onclick = OnSubmitLogout;
                }
                else {
                    lblLogado.style.visibility = "hidden";
                    lblNaoLogado.style.visibility = "visible"; 
                }
            }
           
            function OnSubmitLogout() {  
                Sys.Services.AuthenticationService.logout(OnLogoutComplete); 
                return false;
            }
           
            function OnLogoutComplete(result) {
                lblLogado.style.visibility = "hidden";
                lblNaoLogado.style.visibility = "visible";  
                buttonLoginLogout.innerText = "Efetuar Login";  
                buttonLoginLogout.onclick = OnSubmitLogin;
            }
        
   </form>
</body>
</html>

No exemplo acima utilizamos o método login para autenticar o usuário e, via Javascript, fazemos as manipulações necessárias para assim que o método login retornar o valor (com sucesso ou não), o layout é ajustado, exibindo uma mensagem de que o usuário foi autenticado com sucesso.

Informamos ao método login, além do login e senha do usuário (recuperado dos TextBoxes), um parâmetro booleano que indica se o cookie vai ou não ser persistente. O último parâmetro é a função de callback, a qual será disparada assim que o método de login finalizar o processamento, já que o mesmo é processado assincronamente. Já para o método logout (que irá chamar o método Logout da classe FormsAuthentication), você passa apenas o método que será disparado assim que o método for finalizado, e é neste método que você fará a manipulação do layout para dar um feedback ao usuário que, no caso acima, apenas alteramos o valor do Label para “Não Logado.”.

Este exemplo foi baseado na versão de 06/04/2006 do Atlas e os códigos mostrados acima são baseados no exemplo exibido nos QuickStarts do Atlas. É possível que nas versões futuras do Atlas este objeto de autenticação client-side possa mudar.

A classe estática Membership, encontrada dentro do Namespace System.Web.Security, é usada pelo ASP.NET para validar as credenciais do usuário e gerenciar as configurações do mesmo. Esta classe faz uso da classe FormsAuthentication (já existente nas versões anteriores do ASP.NET) para criar e gerenciar a autenticação do usuário dentro da aplicação Web.

Falando um pouco sobre o seu funcionamento: existe um membro interno chamado s_Provider do tipo MembershipProvider (a classe base para as classes concretas de Membership, como por exemplo o SqlMembershipProvider), o qual receberá a instância da classe concreta. Essa inicialização acontece quando um método interno chamado Initialize é executado. Ele se encarrega de extrair os providers do arquivo Web.Config e instanciá-los para que, quando chamarmos os métodos e propriedades, já sejam efetivamente os métodos e propriedades da classe concreta que queremos utilizar.

Como esta classe encapsula o acesso ao provider específico, ela fornece facilidades como: criação de novos usuários, validação de usuários, gerenciamento de usuários em seu repositório (SQL Server, ActiveDirectory, etc). Como já vimos anteriormente o funcionamento interno desta classe, podemos perceber que o ASP.NET confia no provider especificado no Web.Config para se comunicar com a fonte de dados. Como já sabemos, o .NET Framework inclui a classe SqlMembershipProvider para acesso e persistência dos dados no SQL Server e é este que vamos utilizar no decorrer dos exemplos deste artigo.

Mas esta arquitetura é extensível, ou seja, a qualquer momento eu posso criar o meu próprio provider de Membership, onde eu queira customizá-lo para um outro repositório qualquer. E, para que isso seja possível, é necessário herdarmos da classe abstrata chamada MembershipProvider e customizá-la de acordo com o nosso repositório. Para ilustar o cenário, imaginemos que desejamos ter um provider de Membership sendo persistido em um arquivo XML:

public class XmlMembershipProvider : MembershipProvider
{
    // customizo aqui todos os métodos e
    // propriedades necessárias
}

Depois do provider criado, basta definí-lo nas configurações do Web.Config e começar a utilizá-lo.

A configuração no arquivo Web.Config

Por padrão, todas as aplicações ASP.NET 2.0 já utilizam o Membership. Isso porque dentro do arquivo de configuração machine.config já temos um provider chamado AspNetSqlProvider que utiliza o SqlMembershipProvider. Este provider aponta para um banco de dados chamado ASPNETDB.MDF que encontra-se dentro da pasta App_Data da aplicação e é habilitado quando marcamos a opção AspNetSqlProvider no Web Site Administration Tool. Como o intúito do artigo é mostrar como configurar isso manualmente, vamos especificar o provider em nossa aplicação e configurá-lo para atender as nossas necessidades e, para isso, vamos até o arquivo Web.Config da aplicação para efetuar tal customização.

Já que não queremos utilizar o provider e o banco de dados ASPNETDB.MDF fornecido por padrão pela plataforma, devemos recorrer ao arquivo Web.Config para configurar o provider da forma que precisarmos. Para esta configuração temos os seguintes elementos: membership e providers, que deverão estar declarados dentro do elemento system.web. Estes elementos, por sua vez, possuem uma série de atributos que definem as configurações e possíveis comportamentos e validações que o nosso provider irá desempenhar.

Para cada provider que é adicionado dentro do elemento providers especificamos os atributos de configuração deste provider e, através de atributos definidos no elemento membership, definimos configurações a nível “global de providers“. Veremos cada um dos possíveis atributos (voltado para o uso do SqlMembershipProvider) e seus respectivos valores nas tabelas abaixo:

Agora que já conhecemos todos os parâmetros possíveis dos elementos acima, veremos abaixo um exemplo de como estar configurando isso dentro do arquivo Web.Config da aplicação ASP.NET:

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <clear/>
    <add 
      name="SqlConnectionString"
      connectionString="Data Source=local;Initial Catalog=DBTest;Integrated Security=True;"/>
  </connectionStrings>
  <system.web>
    <membership defaultProvider="SqlMembershipProvider">
      <providers>
        <clear/>
        <add
          name="SqlMembershipProvider" 
          type="System.Web.Security.SqlMembershipProvider" 
          connectionStringName="SqlConnectionString" 
          applicationName="NomeAplicacao" 
          enablePasswordRetrieval="false" 
          enablePasswordReset="true" 
          requiresQuestionAndAnswer="false" 
          requiresUniqueEmail="false" 
          passwordFormat="Hashed" 
          minRequiredNonalphanumericCharacters="0" 
          minRequiredPasswordLength="8" />
      </providers>
    </membership>
  </system.web>
</configuration>

Algumas considerações do código acima: temos uma coleção de connectionStrings, onde através do elemento connectionStrings as informamos e no atributo connectionStringName especificamos o nome do conexão que iremos utilizar; outro ponto importante é o elemento add que é “filho” do elemento providers: como podemos ter uma coleção de providers, podemos adicionar quantos desejarmos e sempre fazemos isso adicionando um novo elemento add e as suas respectivas configurações.

Agora que já temos conhecimento suficiente para criar a infraestrutura e configurar um determinado provider, vamos analisar a classe Membership e seus respectivos membros. Veremos agora como manipular e gerir usuários dentro de uma base de dados SQL Server e, mais tarde, quando estivermos falando sobre os controles que o ASP.NET fornece, veremos como implementar a segurança em uma aplicação utilizando FormsAuthentication.

Não vou me preocupar aqui em mostrar e explicar as propriedades da classe Membership justamente porque são propriedades de somente leitura e apenas devolvem os valores que configuramos no Web.Config para o provider. Nos concentraremos apenas nos métodos, pois são o mais importante e nos dão todas as funcionalidades de manutenção e criação de usuários na base de dados.

Em alguns dos métodos acima comentamos sobre o objeto chamado MembershipUser. Veremos abaixo a lista de métodos e propriedades do mesmo com uma breve descrição.

Depois da teoria veremos abaixo um trecho curto que mostra como chamar esses métodos e propriedades via código:

// Criando Usuário
MembershipCreateStatus status = MembershipCreateStatus.UserRejected;
MembershipUser user =
    Membership.CreateUser(
        "IsraelAece",
        "P@$$w0rd",
        "israel@projetando.net",
        "Questão Password",
        "Resposta Password",
        true,
        out status);
Response.Write(string.Format("Status Criação: {0}", status.ToString());

// Recuperando Usuário
MembershipUser user = Membership.GetUser("IsraelAece");
if(user != null)
{
    Response.Write(string.Format("E-mail: {0}", user.Email));
}

// Excluindo Usuário
if(Membership.Delete("IsraelAece"))
{
    Response.Write("Usuário excluído com sucesso.");
}

// Populando um GridView
this.GridView1.AutoGenerateColumns = true;
this.GridView1.DataSource = Membership.GetAllUsers();
this.GridView1.DataBind();

Integração com outras tabelas

Umas das principais dúvidas é como integrar a tabela de aspnet_Membership com outras tabelas do banco de dados, como por exemplo, uma tabela com o endereço, R.G., C.P.F., entre outros dados. Neste caso cria-se uma coluna chamada UserId do tipo uniqueidentifier nesta tabela “filha” que será uma ForeignKey da tabela aspnet_Membership. Claro que o objeto MembershipUser ainda continuará com as mesmas propriedades e, apesar de um pouco complicado, você teria que sobrescrever o provider para poder contemplar esse novo design do seu objeto.

Para ilustrar, analise a imagem abaixo. Foi criada a relação entre as tabelas através do aspnet_Membership.UserId x Colaboradores.ColaboradorID para firmar o relacionamento entre as tabelas:

O ASP.NET 2.0 inclui uma porção de novos serviços de persistência de dados em um banco de dados. Essa nova arquitetura é chamada de Provider Model e nos dá uma enorme flexibilidade, onde podemos trocar a fonte de dados/persistência e a aplicação continua trabalhando normalmente. Este provider é um módulo do software que estamos desenvolvendo que fornece uma interface genérica para uma fonte de dados, onde abstraem a base de dados. Além disso ser flexível, a qualquer momento podemos trocar a base de dados, essa arquitetura também é extensível, ou seja, se mais tarde quisermos customizar algo, podemos fazer isso sem maiores problemas.

A idéia dentro deste padrão é ter uma classe abstrata, onde dentro dela teremos métodos e propriedades que devem ser implementados nas classes concretas e, através de configurações no arquivo Web.Config, definimos a classe concreta que iremos utilizar para a aplicação. A questão é que essa classe concreta é instanciada em runtime, pois o ASP.NET recupera isso do arquivo de configuração e se encarrega de criar a instância correta da classe para uma determinada funcionalidade.

Essa arquitetura já não é lá muito nova. Se analisarmos o ASP.NET Fóruns ou até mesmo o PetShop 3.0, veremos que eles utilizam uma técnica bem parecida, onde fazem o uso dos padrões Abstract Factory e Factory Method (padrões Criacionais) para garantir essa genericidade. Isso faz com que devemos ter uma classe abstrata por trás a qual as classes concretam as implementam e o runtime se encarrega de criar a instância correta da classe concreta baseando-se nas configurações do arquivo Web.Config.

Essa arquitetura é usada extensivamente dentro do .NET Framework 2.0 (ASP.NET), onde temos classes abstratas para cada situação diferente e, para um determinado repositório de dados, uma classe concreta já implementada. Através da tabela abaixo veremos o nome da funcionalidade, a classe base e as classes concretas que se enquandram dentro do escopo do artigo:

Reparem que para uma determinada classe abstrata, como por exemplo MembershipProvider, já temos, por padrão, algumas classes que a Microsoft implementou para já utilizarmos a funcionalidade. Um exemplo disso é a classe SqlMembershipProvider, a qual utiliza uma base de dados SQL Server 2000 ou superior para disponibilizar o recurso. Como foi dito acima, não se restringe somente à isso. Temos classes para gerencimento de estado, Web Parts, Site Map, Profile, etc., que não foram citados/explicados por não fazerem parte do escopo deste artigo. Se no futuro precisarmos customizar alguma das funcionalidades da tabela acima para uma base de dados, como por exemplo Oracle, basta criarmos uma classe herdando de MembershipProvider ou RoleProvider e implementar os métodos e propriedades exclusivamente para aquela base de dados. Finalmente, para ilustrar essa arquitetura, é mostrado através da figura abaixo o design das classes, já com as devidas denotações de herança entre elas:

Além das classes que vimos acima, temos ainda duas classes estáticas (compartilhadas) que são, também, parte das principais. São estas classes que são expostas para nós, desenvolvedores, utilizarmos e fazermos a chamada aos métodos e propriedades de forma genérica. Essas classes são: Membership e Roles, as quais estão contidas dentro do Namespace System.Web.Security. No caso da classe Membership, existe um membro interno chamado s_Provider do tipo MembershipProvider (a classe base para as classes concretas de Membership, como por exemplo o SqlMembershipProvider), o qual receberá a instância da classe concreta. Essa inicialização acontece quando um método interno chamado Initialize é executado. Ele se encarrega de extrair os providers do arquivo Web.Config e instanciá-los para que, quando chamarmos os métodos e propriedades, já sejam efetivamente os métodos e propriedades da classe concreta que queremos utilizar. O funcionamento é também semelhante para a classe Roles.

Por questões de infraestrutura, utilizaremos no decorrer deste artigo o banco de dados SQL Server 2000. Mas então como prepará-lo para fazer o uso desta funcionalidade? Pois bem, para que o mesmo possa ser utilizado para isso, é necessário criarmos dentro do banco de dados a infraestrutura (Tabelas, Índices, Stored Procedures e Triggers) necessária para a utilização do recurso, que no caso serão Membership e Roles.

Quando instalamos no .NET Framework 2.0, em seu diretório %WinDir%Microsoft.NETFrameworkv2.0.50727 é instalado um utilitário chamado aspnet_regsql.exe. Este utilitário, dados alguns parâmetros, faz todo o trabalho da criação da infraestrutura dentro de um determinado banco de dados SQL Server. Veremos na tabela abaixo os parâmetros que ele aceita:

Abaixo é mostrado (através do prompt de comando do Visual Studio .NET 2005) alguns exemplos do uso do utilitário aspnet_regsql.exe:

Na primeira linha adicionamos as funcionalidades de Membership, Roles, Profile e WebEvents no banco de dados chamado “BancoDados”. Já na segunda opção adicionamos todas as funcionalidades, só que agora utilizando as credenciais do Windows. E, por último, estamos removendo toda a infraestrutura da base de dados. Quando criamos uma destas funcionalidades dentro da base de dados ele inclui uma porção de Tabelas, Stored Procedures, Triggers para que a mesma seja atendida. Se analisarmos o design da base de dados depois disso, veremos a seguinte estrutura:

O Arquivo ASPNETDB.MDF

Quando utilizamos Membership ou qualquer uma destas funcionalidades, se não especificarmos um provider e você não tiver um banco de dados pré-definido para o uso das mesmas, o ASP.NET cria automaticamente dentro do diretório App_Data dentro da aplicação um banco de dados chamado ASPNETDB.MDF, que faz uso do SQL Server 2005 Express Edition. Essa criação se dá quando iniciamos o WSAT – Web Site Administration Tool, onde depois de iniciarmos o provider, o arquivo MDF é criado dentro da pasta App_Data.

Com isso não seria necessário você criar a infraestrutura em uma base de dados assim como mostramos acima, pois o arquivo ASPNETDB.MDF já terá todo o schema necessário para as funcionalidades. Se o volume de usuários não é tão alto e o sistema pouco complexo, ter o ASPNETDB.MDF já resolve a necessidade. Mas quando o nível de usuários aumenta e de alguma forma você precisa fazer o relacionamento da tabela de Usuários com outras tabelas do sistema, é mais interessante ter isso unificado, ou seja, dentro de uma única base de dados.

Há poucos dias atrás, a Microsoft lançou o “Anti-Cross Site Scripting Library V1.0”. Trata-se de uma biblioteca que substitui os métodos HttpUtility.HtmlEncode e HttpUtility.UrlEncode e, com a mesma finalidade, de evitar ataques XSS nas aplicações Web/ASP.NET.

A diferença é que com esta nova biblioteca, os métodos trabalham com os caracteres permitidos “white-listing” ao invés dos caracteres não permitidos “black-listing”, como é o caso dos métodos da classe HttpUtility. Isso fará com que, ao chamar os métodos, o que não estiver contido dentro deste “conjunto” de caracteres válidos, será codificado. Para maiores informações a respeito, façam o download e analisem o documento que vem junto com o pacote.

Matts Gibbs mostra neste artigo, uma nova funcionalidade do ASP.NET 2.0 para encriptar o viewstate da página. Isso pode ser configurado individualmente para cada página através do atributo ViewStateEncryptionMode ou para todas as páginas da aplicação, definindo isso no arquivo Web.Config.

Sempre que construímos uma aplicação Web, é muito comum criarmos áreas administrativas e restritas, onde os usuários poderão gerenciar o conteúdo das páginas, pedidos, clientes, entre muitas outras coisas. Neste artigo explicarei como fazermos para criarmos uma área restrita em sua aplicação.

Devemos criar uma aplicação ASP.NET no Visual Studio. Inicialmente, criaremos uma pasta chamada “Administracao” onde ficaram contidas as páginas restritas. Dentro dela uma página “Default.aspx” e fora dela, devemos ter outro WebForm que será responsável para que usuário faça o Login. Esta página chamará “Login.aspx”. A estrutura de arquivos de nosso projeto ficará algo como:

Depois disso, devemos informar qual será a página de “Start”. Para isso informaremos que a página inicial será a “Default.aspx”, dentro da pasta “Administracao”. Explico: Quando a aplicação é iniciada, a página “Default.aspx” será chamada, ao chamá-la será verificado se o usuário corrente encontra-se ou não logado. Caso não esteja, ele será redirecionado para a página “Login.aspx”, onde ele será obrigado à se autenticar.

Bem, antes de mais nada, devemos construir a página “Login.aspx”, onde devemos ter o formulário para que o usuário possa digitar seu Login e Senha para se identificar. O formulário ficará da seguinte forma:

Em primeiro lugar, quando iniciamos a aplicação, reparem que ele requisitou a página “Default.aspx” dentro do diretório “Administracao”. Como foi verificado que o Usuário não está logado, fui direcionado para a página de Login (“Login.aspx”) e anexado na URL uma QueryString chamada “ReturnURL”, que será a página que o usuário será redirecionado após efetuar a Login (caso seja válido). Outro ponto que gostaria de chamar a atenção é para o CheckBox “Lembrar”. Ele serve para definirmos se o Cookie será ou não persistente, ou seja, se quando o usuário fechar o Browser e abri-lo novamente, já ficará ou não autenticado.

Antes de codificarmos o evento Click do botão de Login, vamos ver as configurações que devemos fazer no arquivo Web.Config:

Informamos no arquivo Web.Config a página que será efetuado o Login e também informamos que a pasta “Administração” será restrita. A partir disso o usuário deverá efetuar o Login antes de visualizar o conteúdo da pasta “Administracao”.

Agora vamos criar uma tabela no SQL Server chamada “Administradores” onde armazenará o cadastro dos Administradores do Sistema. Depois de criada, no evento Click do Botão de Login, devemos ir até o SQL Server e verificar se esse usuário existe na Base de Dados. Caso positivo, ele será redirecionado para a página que encontra-se na QueryString “ReturnURL”, caso contrário, não podemos permitir o acesso.

A Tabela Administradores terá apenas o seguintes campos: Nome (Varchar(50)), Login(Varchar(10)) e Senha(Varchar(6)). E o evento Click ficará da seguinte forma:

Como podem ver, em primeiro lugar importamos os Namespaces necessários, no caso: System.Data.SqlClient e System.Web.Security. Depois, abrimos conexão com a Base de Dados e através de uma query, passamos como parâmetros o Login e Senha, verificamos se existe algum registro que atenda à essa condição. Caso exista, o usuário é redirecionado para a página “Default.aspx” dentro da pasta “Administracao”, caso contrário uma mensagem será exibida para ele, informando que o acesso foi negado. Lembrando que o CheckBox é passado como o segundo parâmetro para a Sub RedirectFromLoginPage (Linha 31), informando se é ou não para manter o Cookie persistente.

Importante: Não há necessidade de nos preocuparmos em tratarmos os apóstrofos “‘” e ponto-e-vírgula “;” para aqueles que tentarem a “SQL Injection”, pois quando trabalhamos com Parameters, eles ficam encarregados de tratarem isso automaticamente.

Depois de validado, somos direcionados para a página requisitada anteriormente. Veja abaixo:

Como passamos para a Sub RedirectFromLoginPage o Login do Usuário (Linha 30 do Código 2), é possível recuperarmos isso durante a sua sessão. Para isso pode fazer:

O que nos restou agora é fazermos o “Logout” do Usuário. Para isso, utilizaremos o LinkButton “Logout” e assim, ao clicar, a sessão do usuário será finalizada. Veja o exemplo abaixo:

Utilizamos a Sub SignOut da classe FormsAuthentication para finalizar a sessão do Usuário, e assim ele será novamente redirecionado para a página de Login (“Login.aspx”).

Conclusão: Com o ASP.NET a segurança em nossas aplicações Web ficaram bem mais fáceis de serem implementadas e bem mais seguras. Este artigo explica a parte superficial. Há muitas “features” que possam ser utilizadas para garantirmos o máximo de segurança possível, mas é claro que tudo dependerá de cada Aplicação.

Neste artigo apresentarei um overview do novo objeto do ASP.NET 2.0, chamado Profile qual tem a finalidade específica de armazenar informações de um determinado usuário em seu contexto.

O Profile é bem semelhante ao objeto Session atual, onde para cada usuário que temos em nossa aplicação Web é criado um Profile para ele. Até então funciona da mesma forma que o objeto Session. Mas o mais interessante está por vir, ou seja, quando fechamos o browser, a Session é perdida. Já utilizando o Profile ele se mantém persistente mesmo depois do usuário fechar o browser.

Isso se deve graças ao uso, por default, do Microsoft Access, onde são armazenadas estas informações, que fica dentro de uma pasta chamada Data, dentro da sua aplicação. Vale lembrar que é perfeitamente possível o uso de uma outra Base de Dados para termos uma melhor performance, como por exemplo SQL Server ou Oracle. Veremos este tópico um pouco mais adiante, em um futuro artigo.

Além da vantagem de se manter persistente mesmo depois de fechado o Browser, o Profile ainda tem uma vantagem, que particularmente considero fantástica, que é fortemente tipado (strongly typed), ao contrário da Session, que por sua vez aceitava um Object. Além disso, o IntelliSense já reconhece as propriedades, tornando assim o desenvolvimento mais rápido e menos propício a erros.

Definindo o Profile

Você deve utilizar o arquivo Web.Config para gerar a estrutura que o teu objeto Profile irá ter. Temos à nossa disposição o elemento profile, onde definimos as propriedades que vamos disponibilizar. O cenário é termos dentro do Profile, o Nome e Email do Usuário. Abaixo o código do arquivo Web.Config que define o Profile:

Analisando o código acima, vemos o elemento anonymousIdentification que especificará que o Profile será criado para usuários anônimos ou autenticados. Se definí-lo com False e tentar atribuir algum valor as propriedades em runtime e o usuário não estiver autenticado, uma Exception será lançada. Já o atributo allowAnonymous é requerido quando as propriedades são usadas com usuários anônimos.

O código para atribuir um valor as propriedades, fica da seguinte forma:

Como já podemos ver na Figura 1 logo abaixo, o Intellisense já passa a interpretar as propriedades que definimos no Web.Config:

Repare que o tipo do dado não é definido. Isso porque o default, quando não informamos é System.String. Caso queria definir um tipo Inteiro ou qualquer outro tipo, tem o atributo type, onde define-se o tipo de dado que queira para aquela propriedade.

Profile Groups

Quando começamos a criar várias propriedades dentro do arquivo Web.Config para utilizarmos no Profile, começamos a ter a necessidade de separar algumas delas em grupos para que facilite a compreensão e organização. Para isso temos o elemento group, onde dentro dele colocamos as propriedades pertinentes ao mesmo. Se quisermos adicionar um grupo chamando Endereco, contendo Rua, Cidade, Estado, fazemos:

E para acessá-los, o código fica:

Tipos Complexos

Muitas vezes, criamos objetos complexos que encapsulam alguma lógica e funcionalidades específicas. Um exemplo prático disso é quando criamos um objeto do tipo Carrinho de Compras para aplicações de comércio eletrônico. Neste caso, o ideal é colocarmos este tipo de objeto no Profile e assim fazer o uso destas funcionalidades. O Profile permite definir estes tipos complexos para ser gerenciado/armazenado, como por exemplo uma classe.

Para exemplificar como isso funciona realmente, criaremos uma classe (que é um tipo complexo) onde teremos um objeto que será o Carrinho de Compras do nosso Cliente. Esta classe armazenará os produtos que o cliente desejar incluir no Carrinho além de nos retornar o valor total do produtos e claro, podemos dar muito mais funcionalidades a ela se desejarmos. Primeiramente o código da classe que contém as propriedades para a estrutura do Produto:

Depois de criada a classe que tem a estrutura do nosso Produto, criaremos a seguir a classe que conterá as funcionalidades do nosso Carrinho de Compras, incluindo dentro dela também a capacidade de armazenar os produtos que são adicionados ao carrinho pelo usuário:

Como podemos ver, é um código simples, onde temos um método chamado AdicionarProduto que é responsável por adicionar um novo produto a coleção de produtos. Uma propriedade que nos retorna o valor total dos Produtos e outra para resgatar a coleção de produtos que o usuário selecionou.

O que é importante reparar é que as duas classes necessitam do atributo Serializable, que se faz necessário para o armazenamento/persistência do objeto pelo Profile.

Da mesma forma que criamos, um pouco mais acima, as simples propriedades e seus grupos no arquivo Web.Config, devemos fazer o mesmo neste caso de tipos complexos. A forma com qual é declarada muda um pouco, tendo que definir alguns atributos como é mostrado abaixo:

O que notamos de novidade na declaração de tipos complexos no Web.Config é o elemento serializeAs que define qual o tipo de serialização do objeto. Feito isso, agora já poderemos utilizar o nosso Carrinho de Compras pelo site, apenas tendo o cuidado de, quando for utilizá-lo pela primeira vez, instanciá-lo para poder inicializá-lo. Veremos abaixo um simples exemplo de como adicionar novos produtos ao Carrinho e como exibir o seu conteúdo em um controle ASP.NET qualquer:

Como vemos, verificamos se existe alguma instância do nosso objeto CarrinhoCompras em nosso Profile. Em seguida, criamos dois produtos e adicionamos neste carrinho. Através da propriedade Produtos resgatamos todos os produtos que estão dentro do Carrinho e preenchemos nosso controle GridView e um Label com a propriedade Total, assim como é ilustrado na figura abaixo:

CONCLUSÃO: Vimos aqui a nova forma de armazenarmos objetos pertencentes à um determinado usuário que chamamos de Profile. Há ainda outras funcionalidades como por exemplo a configuração e utilização de outros Providers e também como gerenciar e exibir (relatórios) de Profiles. Funcionalidades quais veremos em um futuro artigo desta série para não ficar muito desgastante.

Como já foi dito anteriormente, os Profiles, por default, são armazenados em um banco do dados do tipo Microsoft Access dentro da pasta App_Data da aplicação. Haverá casos, onde temos a nosso dispor, uma base de dados SQL Server, que é infinitamente mais robusta que um simples arquivo MDB do Microsoft Access, e com isso podemos utilizá-la para que a aplicação grave neste servidor SQL Server as informações/dados referentes aos Profiles da mesma.

Para que isso seja possível, temos no ASP.NET o que chamamos de um Profile Provider, que permitirá você especificar onde as informações serão salvas, definindo isso em seu arquivo de configuração (Web.Config ou Machine.Config).

O ASP.NET nos fornece, já intrinsicamente, um provider/classe chamado SqlProfileProvider. Esta classe deriva de uma classe base chamada ProfileProvider, ficando assim flexível para quando você precisar criar seu próprio Profile Provider para um banco de dados específico, como por exemplo MySQL, Oracle, SyBase, etc.

Mas antes de utilizarmos o SqlProfileProvider temos que fazer algumas configurações fora da nossa aplicação, ou seja, rodarmos um aplicativo “*.exe” que vem juntamente com o .NET Framework 2.0, chamado aspnet_regsql, que você poderá encontrá-lo no seguinte path: WindowsMicrosoft.NETFramework[versao]. Este processo se faz necessário porque através dele, é que são geradas as Stored Procedures dentro do servidor SQL Server. Stored Procedures que são executadas pelo SqlProfileProvider para a manipulação dos dados dos Profiles.

Feito este processo, o que se tem a fazer agora é configurar o Provider, no nosso caso, o SqlProfileProvider no arquivo Web.Config da aplicação. Abaixo um trecho do código do arquivo Web.Config onde é configurado o SqlProfileProvider a nível da nossa aplicação (se desejar definir este Provider para todas as aplicações, poderá fazer esta configuração no arquivo Machine.Config):

Como vemos, dentro do elemento providers temos o nome e o tipo (a classe) que no nosso caso é a SqlProfileProvider que fará o trabalho para gerir os Profiles dentro do SQL Server. Temos também um atributo chamado connectionStringName onde indicamos qual é a string de conexão, que informará o servidor e o banco de dados que será utilizado. Caso você tenha customizado uma classe para um banco de dados qualquer, o tipo (type) mudará, onde voce deverá informar o tipo da classe criada, inclusive o Namespace.

Agora basta utilizar os Profiles normalmente, como foi explicado na primeira parte deste artigo, e os dados já serão gravados dentro do SQL Server especificado na Connection String do arquivo Web.Config.

Gerenciando Profiles – Relatórios

Temos uma classe chamada ProfileManager que nos permite gerenciar os Profiles da nossa aplicação. É através desta classe, que nos é fornecido uma série de métodos e propriedades estáticos para as tarefas mais comuns, como por exemplo excluir, exibir, recuperar Profiles, etc.

Com isso, podemos criar uma aplicação Console ou mesmo um Windows Service que gerencie os Profiles da nossa aplicação, colocando-lá todas as manipulações que desejamos fazer com os Profiles. Abaixo os métodos e propriedades da classe ProfileManager:

Ainda temos um objeto bastante importante chamado ProfileInfo, que contém informações de um Profile específico. Veremos na tabela abaixo as propriedades desta classe:

Abaixo um exemplo de como utilizar a classe ProfileManager dentro de uma aplicação qualquer:

Como o método GetAllProfiles retorna uma coleção de objetos do tipo ProfileInfo, podemos tranquilamente definí-lo como DataSource de um container de dados para exibi-lo para o usuário assim como é mostrado no código 2, logo acima.

CONCLUSÃO: Nesta situação, os providers e os Profiles são bastante úteis, onde é encapsulado uma porção de códigos para nos ajudar a gerenciar essas informações que temos em aplicações Web/ASP.NET. Claro que se quiser utilizar uma outra base de dados, não SQL Server, terá mesmo que customizar um Provider para esta, herdando da classe base ProfileProvider. E com o uso da classe ProfileManager, temos acesso e gerenciamento dos Profiles da nossa aplicação, evitando trabalhar diretamente com código SQL.