Atualize a autenticação de seu site com a nova API Membership do ASP.NET 2.0

Por Dino Esposito e Andrea Saltarello

Partes deste artigo são baseadas em uma versão de pré-lançamento do ASP.NET 2.0. Essas seções poderão sofrer alterações.

Este artigo discute:

  • Técnicas de autenticação comuns para aplicativos ASP.NET

  • A API Membership e o modelo de provedor no ASP.NET 2.0

  • Segurança e autorização baseada em papéis

Este artigo usa as seguintes tecnologias:
ASP.NET, Visual Basic

Você pode baixar o código em:
Membership.exe (148 KB)

Em sua primeira versão, o ASP.NET introduziu a autenticação de formulários. Isso ofereceu uma poderosa estrutura para manuseio da autenticação do usuário de modo seguro e com uma API fácil de utilizar. A base da autenticação de formulários não mudou no ASP.NET 2.0, portanto a maioria dos truques e técnicas ainda são válidos. Porém, houve um grande volume de trabalho no ASP.NET 2.0 para expor um novo sistema de associação que torne ainda mais fácil criar sistemas mais poderosos para autenticação e gerenciamento de usuários. Ao explorar os pontos básicos do modelo do provedor (no qual esse novo sistema de associação se baseia) e sua forte integração com autenticação de formulários, você inevitavelmente imaginará: como isso afeta meu código existente e o banco de dados de usuários e papéis?

À primeira vista, o mecanismo de autenticação totalmente automática do ASP.NET 2.0 parece que só funciona se você reescrever todos os códigos de validação ASP.NET 1.x existentes dos quais você dependa, incluindo os códigos de gerenciamento de senhas e papéis. Além disso, parece que o ASP.NET 2.0 exige que você altere seu banco de dados de usuários para obedecer ao esquema do SQL Server ™ ou Active Directory® predefinido. Porém, essas aparências enganam.

As chaves para a autenticação do ASP.NET 2.0 são a nova API Membership (uma API genérica, pública, para autenticação de usuários) e o modelo de provedor (a especificação subjacente que o torna possível). No ASP.NET 2.0, a autenticação é construída sobre um modelo extensível, baseado em provedor. Essa abordagem permite que você altere facilmente o código de validação subjacente e o gerenciamento de usuários sem ter de modificar o código que interage com o sistema de associação. Isso significa que você pode adaptar facilmente seu código existente para conectar-se à maquinaria de autenticação do ASP.NET 2.0.

Veremos os detalhes técnicos da API Membership e sua natureza intrinsecamente extensível, com base em provedores plugáveis. Utilizaremos um mecanismo já existente de autenticação ASP.NET 1.x e o converteremos para o ASP.NET 2.0, expondo os mecanismos de autenticação existentes por meio da nova API Membership. O código a ser escrito é mínimo, e o nível de reutilização é maior do que você imagina.

Autenticação ASP.NET

No ASP.NET 1.x, implementar a autenticação de formulários é um procedimento em várias etapas. Primeiro, ajuste a seção <authentication> do arquivo Web.config do aplicativo para que ela registre a autenticação baseada em formulários. Depois escreva a página de login que será exibida aos usuários solicitantes. Finalmente, você deve planejar uma estratégia de autenticação, configurar o armazenamento necessário e implementar qualquer código necessário. Após incluir o seguinte no arquivo Web.config, qualquer solicitação de página que não tenha um tíquete de autenticação válido será redirecionada para login.aspx:

<authentication mode="Forms">
   <forms loginUrl="login.aspx" protection="All" />
</authentication>
<authorization>
   <deny users="?"/>
</authorization>

Um módulo HTTP especial, chamado FormsAuthenticationModule, encarrega-se dessa verificação. Esse módulo conecta-se a dois eventos de pipeline: AuthenticateRequest e EndRequest. Quando a solicitação é interceptada e está pronta para autenticação, o módulo busca um tíquete de autenticação contendo as credenciais do usuário. O tíquete de autenticação é um cookie HTTP criptografado com um nome configurável (.ASPXAUTH é o padrão). Se não encontrar um tíquete válido, a solicitação será redirecionada para a página de login especificada, cujo URL foi lido do arquivo de configuração. (Para informações sobre a implementação desse processo sem o cookie, veja a barra lateral "Autenticação sem cookies".)

A página de login é um formulário Web que contém, no mínimo, duas caixas de texto e um botão Submit (Enviar). Não existe um modelo predefinido nem um layout obrigatório para a página de login. Cada aplicativo pode fornecer a página de login mais adequada às suas necessidades. Mas um elemento essencial é o código ligado ao evento de postagem, geralmente o evento Click de um Button ou LinkButton. Ele reúne as credenciais do usuário (além de outros dados disponíveis, como a caixa de seleção Remember Me) e as valida em relação ao banco de dados de usuários.

A Figura 1 mostra o código ASP.NET 1.x típico. No seu cerne está o método personalizado AuthenticateUser. Ele recebe o nome e senha do usuário e consulta o banco de dados de usuários para determinar se o nome e a senha representam uma conta válida.

Esse tipo de código é bem comum e, o que é mais importante, funciona bem. Então, qual é o problema? Se você está atualizando um aplicativo existente, poderá ignorar os novos recursos economizadores de tempo do ASP.NET 2.0 ou eliminar a maior parte do código existente e reescrevê-lo para referenciar outro banco de dados (normalmente, o SQL Server) e outro esquema. Mas em um aplicativo razoavelmente complexo, você terá de lidar com muito mais que apenas um código simples que verifica credenciais. Em vez disso, você provavelmente terá um objeto gerenciador de usuários, gerenciamento de e-mails e papéis, um protocolo de pergunta/resposta para lembrete e redefinição de senhas, diretrizes de senhas etc.

A importância de obedecer ao estilo de programação do ASP.NET 2.0 não é uma questão de funcionalidade. Quer você prefira recompilar um código antigo mas que ainda funciona ou abraçar os novos e quentes componentes do ASP.NET 2.0, o comportamento real do sistema, cuja finalidade é a autenticação dos usuários, não mudará. Mas se utilizar o modelo do ASP.NET 2.0 você poderá usufruir os novos controles e uma nova API, sob medida, que se estende da associação ao papel e ao gerenciamento de senhas. Uma série de controles relacionados à segurança (veja a barra lateral, "Controles de segurança no ASP.NET 2.0") torna muito rápida a construção de recursos de login/logout. Você tem controles GUI já prontos que permitem aos usuários fazer login e logout, exibir o status do login, alterar senhas e obter lembretes, além de criar novas contas de usuário. E esses não são apenas recursos ocasionais, são recursos comuns exigidos por quase todos os aplicativos para a Web.

Cc580602.Membership01(pt-br,MSDN.10).gif
Figura 2 - Ferramenta de Configuração do ASP.NET 2.0

A maioria dos aplicativos também necessita de um sistema de back-end que permita aos administradores criar e administrar usuários, senhas e papéis. O ASP.NET 2.0 fornece novos controles para tarefas relacionadas à IU, uma ferramenta de configuração IDE (veja a Figura 2) e uma API comum, extensível, para chamar funções de gerenciamento de associações e papéis.

As sementes da API Membership

Para compreender o real valor agregado de uma API extensível comum para funções personalizáveis comuns, vejamos mais detalhadamente um recurso relacionado à segurança no ASP.NET 1.x que recentemente foi alvo de críticas: o armazenamento de senhas no arquivo Web.config. É questionável que qualquer desenvolvedor empresarial chegue a pensar em armazenar informações do usuário deste modo (ou, pior ainda, no arquivo Web.config mas com as senhas em texto sem formatação):

<authentication mode="Forms">
   <forms loginUrl="login.aspx" protection="All">
      <credentials passwordFormat="SHA1">
         <user name="Joe" password="07B7F3EE06F278D" />
         <user name="Bob" password="B966BE960E7CBBD" />
      </credentials>
   </forms>
</authentication>

Então você deve estar imaginando por que o ASP.NET permitiria armazenar credenciais do usuário em um arquivo de configuração. Bem, ao fazê-lo você dá à maquinaria de autenticação do ASP.NET um ponto de extremidade claro e fixo onde ele pode buscar dados do usuário. Se você tiver credenciais armazenadas no arquivo Web.config, o seguinte código executado dentro de uma página de login funciona muito bem:

If FormsAuthentication.Authenticate(user, password) Then
   FormsAuthentication.RedirectFromLoginPage(user, false)
Else
   errorMsg.Text = "Sorry, that's not it."
End If

Esse código difere do apresentado na Figura 1 em apenas um pequeno detalhe, mas que é essencial. A tarefa de autenticar usuários é delegada a um método chamado Authenticate, que é definido estaticamente na classe FormsAuthentication disponível do assembly System.Web.

Geralmente há duas formas de considerar este recurso: Você pode considerar o método Authenticate como um atalho interno (e geralmente não muito útil) para verificar nomes de usuários armazenados em um arquivo XML. Ou, em uma consideração mais elaborada, imaginar o método Authenticate como a interface pública e imutável de um recurso do sistema. A disponibilidade de uma interface imutável permite criar componentes visuais que interajam com a página e com outros controles de modo totalmente automático, sem código e declarativo.

Como criar um controle de login da perspectiva do ASP.NET 1.x? Como você trataria a autenticação? Parece que o modo mais simples é ligar o evento Click do botão Submit (Enviar) a um evento definido pelo usuário. O autor da página trata do evento, verifica as credenciais informadas e retorna verdadeiro ou falso. Esse modelo funciona, mas exige um acoplamento bem estreito entre a página e o formulário de login. Também é necessário escrever algum código. Como você depende de uma interface pública e imutável para acionar o processo de autenticação, poderá embutir a maior parte do código já mencionado no componente de login. As páginas resultantes usando o componente de login serão páginas com código zero. Naturalmente, é possível estender esse padrão bem além das fronteiras da função de login.

Personalizando a Autenticação com Membership (Associação)

Uma API pública e fixa geralmente implica um comportamento conhecido e fixo, uma estratégia e um algoritmo subjacente. Autenticação, por exemplo, significa verificar as credenciais. Mas cada aplicativo tem sua maneira própria de fazer isso, por meio de diferentes bancos de dados, diferentes esquemas, diferentes procedimentos armazenados etc. Como você pode ver, a mesma estratégia pode ser implementada por diferentes algoritmos.

Figura 3 Esquema 1.xNo ASP.NET 1.x, o método Authenticate representa uma API pública e fixa para aplicar uma estratégia conhecida, mas sua implementação não é inteligente o bastante para suportar componentes intercambiáveis que personalizem o modo como ocorre a autenticação (o algoritmo real). No ASP.NET 2.0, a API Membership realiza diversas tarefas relacionadas à autenticação e ao gerenciamento de usuários. Diferentemente do método Authenticate usado no ASP.NET 1.x, a API Membership suporta o modelo de provedor ASP.NET 2.0, que permite que você especifique sua própria implementação de determinado recurso. A Figura 3 mostra o esquema de associação do ASP.NET 1.x; a Figura 4 mostra o mesmo esquema no ASP.NET 2.0. Ao escrever e registrar um componente personalizado (o provedor da associação), você instrui a API pública Membership a usar seus métodos personalizados (em oposição aos métodos padrão) para realizar tarefas de autenticação. Esse modelo permite desconectar a implementação padrão de determinado recurso (neste caso, a autenticação do usuário) e conectar a sua própria.

Cc580602.Membership02(pt-br,MSDN.10).gif
Figura 3 - Esquema 1.x

Figura 4 Esquema 2.0Se você for um purista no que diz respeito ao software, ou se simplesmente prefere termos formais, esses conceitos provavelmente serão bem familiares. Essa é apenas uma instância do padrão da estratégia. Um padrão de estratégia indica um comportamento esperado (por exemplo, classificação) que pode ser implementado por meio de diversos algoritmos intercambiáveis (por exemplo, classificação rápida ou classificação por mesclagem). Depois cada aplicativo seleciona o algoritmo mais adequado. Quanto à ASP.NET Membership, o provedor de associação implementará o comportamento esperado com base em um algoritmo personalizado como o Active Directory, um banco de dados SQL Server ou um banco de dados Oracle.

Cc580602.Membership03(pt-br,MSDN.10).gif
Figura 4 - Esquema 2.0

Ao registrar seu provedor de associação preferido no arquivo Web.config, você instrui seu aplicativo para criar uma instância de um objeto que ele pode na verdade não conhecer no momento da compilação. Esse modelo é chamado de padrão de fábrica.

Usando a API Membership

A nova classe Membership no ASP.NET 2.0 reduz a quantidade de código que você tem de escrever para autenticar usuários e fornece uma infra-estrutura interna para o gerenciamento de papéis. Usando os recursos do subsistema Membership, você pode reescrever o código que autentica um usuário, como mostrado no código a seguir:

Sub Logon_Click(sender As Object, e As EventArgs) 
   Dim user As String = userName.Text
   Dim password As String = passWord.Text
   If (Membership.ValidateUser(user, password))
      FormsAuthentication.RedirectFromLoginPage(user, false)
   Else
      errorMsg.Text = "Sorry, that's not it."
   End If
End Sub

Esse código é quase idêntico ao que você escreveria para um aplicativo ASP.NET 1.x; a diferença é que esse código usa o método estático Membership.ValidateUser em vez do método estático FormsAuthentication.Authenticate. O comportamento real do ValidateUser é determinado pelo provedor de dados que está registrado para uso. Todos os provedores têm de expor uma interface padrão que seja sofisticada o bastante para incorporar várias tarefas relativas à associação. O ValidateUser fornece um invólucro para essas APIs, expondo um só método que pode ser utilizado por seu aplicativo independentemente do provedor em uso. (O provedor que deve ser usado está registrado no arquivo Web.config do aplicativo.) Você pode mudar o provedor, e posteriormente alterar o mecanismo de autenticação, sem ter de recompilar o aplicativo e sem ter de alterar nenhuma parte do código na página que usa a API Membership.

O uso dos recursos de associação do ASP.NET 2.0 não requer uma compreensão profunda das ferramentas e dos mecanismos de armazenagem de dados (como o SQL Server, procedimentos armazenados e criptografia). Embora ainda forneça inúmeras opções de configuração, a API Membership torna transparentes os diversos detalhes de como as credenciais são armazenadas e verificadas. A classe Membership contém algumas propriedades e alguns métodos estáticos que você utiliza para obter uma identidade única para cada usuário conectado. Essas informações do usuário também podem ser usadas com outros serviços do ASP.NET, inclusive funções baseadas em papéis e recursos de personalização.

A Figura 5 descreve as diversas propriedades disponíveis para a classe Membership. Elas todas são propriedades estáticas com implementações bem simples. Cada propriedade simplesmente acessa o membro correspondente no provedor atual.

Como seu nome sugere, o método Initialize garante que a classe Membership esteja corretamente configurada e alinhada com as opções no arquivo Web.config. A propriedade Provider retorna uma referência ao provedor de associação atualmente em uso. O método Initialize e a propriedade Provider são então usados internamente em muitas das propriedades públicas estáticas. Por exemplo, quando você acessa Membership.PasswordAttemptWindow, o método Initialize é chamado primeiro para garantir que a configuração esteja completa e então a propriedade PasswordAttemptWindow é delegada para o provedor atual:

Public Shared ReadOnly Property PasswordAttemptWindow As Integer
  Get
     Membership.Initialize()
     Return Membership.Provider.PasswordAttemptWindow
  End Get
End Property

Desde a versão Beta 2, o ASP.NET 2.0 é fornecido com um provedor predefinido voltado para o Active Directory (System.Web.Security.ActiveDirectoryMembershipProvider) e outro para bancos de dados SQL Server e arquivos MDF no SQL Server Express (System.Web.Security.SqlMembershipProvider). Os provedores do Microsoft® Access, que estavam disponíveis no Beta 1, não são mais incluídos no ASP.NET 2.0, mas podem retornar como um código-fonte de amostra no futuro. Você pode obter a lista dos provedores registrados por meio da coleção Providers. É importante observar que algumas propriedades são específicas do provedor e podem não ser compatíveis com outros provedores. E, naturalmente, os provedores podem implementar outras propriedades, além das discutidas neste artigo.

A Figura 6 lista os métodos da classe Membership, incluindo métodos para criar, atualizar e excluir usuários. Alguns dos métodos retornam ou aceitam um objeto MembershipUser, que contém informações sobre o usuário, armazenadas no sistema. Para poder utilizar um armazenamento de dados personalizado, como um banco de dados existente, você pode criar seu próprio provedor, tornando seu armazenamento de dados acessível a qualquer aplicativo que utilize a API Membership. Você também pode registrar vários provedores em um aplicativo, permitindo que o aplicativo selecione o provedor adequado na hora da execução.

Normalmente é usada a ferramenta Web Site Administration (veja a Figura 2) para gerenciamento offline de usuários e senhas. Porém, para criar um novo usuário programaticamente, basta chamar o método CreateUser. Vamos supor que você tenha uma página de login com dois painéis mutuamente exclusivos, um para usuários registrados e outro para que novos usuários registrem uma nova conta (veja a Figura 7).

Cc580602.Membership04(pt-br,MSDN.10).gif
Figura 7 - Páginas de login separadas

Se você clicar no link que permite o registro de novos usuários, a página muda de painel e exibe o formulário de entrada para coletar o nome e a senha do novo usuário. O manipulador de cliques para o botão Add (Adicionar) executa o seguinte código:

Sub AddNewUser_Click(sender As Object, e As EventArgs)
  Membership.CreateUser(NewUserName.Text, NewUserPassword.Text)
  NewUserPanel.Visible = False
  LogUserPanel.Visible = True
End Sub

Observe que a sobrecarga de CreateUser usada neste exemplo na verdade não funcionará com a configuração de associação padrão. Embora a configuração padrão permita reinicializações com base em senhas, ela exige uma pergunta e uma resposta para esta operação. O resultado é que ao utilizar a configuração de associação padrão, você terá de utilizar uma das outras sobrecargas.

Para excluir um usuário, use o método DeleteUser, que aceita o nome de usuário registrado do usuário a ser excluído:

Membership.DeleteUser(userName)

A recuperação de informações sobre determinado usuário também é fácil assim, por meio do método GetUser. Esse método recebe o nome do usuário e retorna um objeto MembershipUser:

MembershipUser user = Membership.GetUser("AndreaS")

Depois de obter um objeto MembershipUser, você saberá tudo o que preciso sobre um determinado usuário e poderá, por exemplo, alterar programaticamente a senha. Geralmente um aplicativo precisa permitir diversas operações de senhas, como alterá-la ou redefini-la, ou enviá-la a um usuário (possivelmente com um protocolo de desafio de pergunta/resposta). Todas essas funções são suportadas pela API Membership, mas não necessariamente pelo provedor subjacente. Se o provedor não suportar determinado recurso, será gerada uma exceção quando o método for chamado.

Para usar o método ChangePassword, você tem de fornecer a senha antiga e a nova senha:

Dim user As MembershipUser = Membership.GetUser("AndreaS")
user.ChangePassword(user.GetPassword(), newPassword)

Mas isso pode não funcionar em algumas implementações, como se você tiver configurado o sistema de associação para armazenar as senhas em seu banco de dados em hash e/ou salteadas, o que é uma medida comum de segurança. Nesse caso, não é possível recuperar a senha original, e a única opção disponível caso o usuário tenha esquecido a senha atual será redefinir a senha. Para redefinir a senha, use o método ResetPassword:

Dim user As MembershipUser = Membership.GetUser("AndreaS")
string newPassword = user.ResetPassword()

O subsistema de seu aplicativo que chama ResetPassword também é responsável por enviar a nova senha ao usuário (por exemplo, via e-mail). Tanto o método GetPassword quanto o método ResetPassword têm uma segunda sobrecarga que utiliza um parâmetro de seqüência. Se for especificada, essa seqüência representa a resposta à pergunta de "esqueceu a senha" do usuário.

A capacidade de redefinir uma senha, além do suporte para o desafio da senha, é específica do provedor e é configurada no arquivo Web.config. A pergunta do desafio da senha é exposta como um membro ler/gravar da classe MembershipUser. Quando o usuário é criado, a pergunta e a resposta do desafio devem ser definidas e armazenadas no banco de dados de associação.

Escrevendo um provedor personalizado

Quando você estiver familiarizado com o armazenamento de dados de associação em um arquivo de banco de dados do SQL Server Express e com o esquema padrão adotado pelo ASP.NET, não resta muito a fazer além de utilizar a ferramenta Web Site Administration para criar e preencher o banco de dados para o aplicativo atual. Mas e se você quiser usar um banco de dados Oracle ou um banco de dados SQL Server com um esquema personalizado? Ou, o que é mais importante, e se você investiu tempo e dinheiro construindo um sistema completo de associação para seu aplicativo ASP.NET 1.x atual? Não se preocupe. Você pode reutilizar este código, no todo ou em parte, desde que queira e saiba escrever um provedor personalizado de associação.

Todos os provedores usados no ASP.NET 2.0 implementam um conjunto comum de membros: os definidos pela classe abstrata ProviderBase. A classe vem com um método virtual (Initialize) e duas propriedades virtuais (Name e Description). A propriedade Name retorna o nome oficial da classe do provedor. O método Initialize usa o nome do provedor e um objeto de coleção de nomes/valores incluídos no conteúdo da seção de configuração do provedor. Diversas classes abstratas são provenientes de ProviderBase e atuam como as classes básicas para diversas tarefas específicas do provedor, inclusive MembershipProvider, RoleProvider e mais algumas.

MembershipProvider não pode ser utilizada diretamente, pois consiste em diversos métodos abstratos. Para construir um provedor de associação personalizado, é preciso herdar de MembershipProvider. A Figura 8 fornece a lista de propriedades e métodos virtuais a serem substituídos.

A Figura 9 mostra uma classe extremamente simples, mas utilizável, que incorpora o código de autenticação usado na Figura 1 para um aplicativo ASP.NET 1.x. Como pode-se ver, a maioria dos métodos e propriedades têm uma implementação nula que apenas gera uma exceção. Já a implementação de ValidateUser chama de volta parte do código importado do aplicativo ASP.NET 1.x. Quanto mais recursos você tiver, mais poderá portar para o ASP.NET 2.0 substituindo outros métodos e propriedades de modo mais significativo. Por exemplo, se o código existente inclui um objeto gerente de usuário para realizar as operações Criar/Ler/Atualizar/Excluir (CRUD) nos usuários, você pode facilmente mapear esses membros para os métodos do provedor de associação personalizado. O código correspondente para este artigo, que você pode baixar do site da MSDN®Magazine, demonstra como portar tal recurso para o ASP.NET 2.0.

Para registrar o novo provedor de associação, é preciso ajustar o arquivo Web.config do seguinte modo:

<membership defaultProvider="MyMembershipProvider">
   <providers>
     <add name="MyMembershipProvider" 
          type="MsdnMag.MyMembershipProvider" />
   </providers>
</membership>

Basta adicionar este código ao arquivo Web.config de seu aplicativo no nó <system.web> e pronto. De agora em diante, qualquer chamada para a classe Membership será resolvida chamando os métodos da sua classe de provedor. A Figura 10 mostra o uso da ferramenta Web Site Administration para selecionar o novo provedor.

Cc580602.Membership05(pt-br,MSDN.10).gif
Figura 10 - Gerenciando o novo provedor de associação

O padrão adaptador

Agora você já viu que o código de associação do ASP.NET 1.x pode ter suas ferramentas adequadamente alteradas e pode ser reutilizado em aplicativos do ASP.NET 2.0. Por mais complexo que seja o mecanismo de autenticação existente, sempre é possível reutilizar grandes partes e integrar essas partes com a nova e sofisticada infra-estrutura de segurança e autenticação do ASP.NET 2.0. Para alcançar esses resultados, é essencial ter outro padrão de projeto popular: o padrão adaptador.

O padrão adaptador converte a interface de programação de uma classe A em uma interface B que um cliente classe C entenda plenamente. Em outras palavras, o padrão adaptador designa uma classe que ajusta a implementação de outra classe e expõe essa segunda classe por uma interface diferente. Nesse contexto, a característica mais interessante do padrão adaptador é que ele permite que a classe do provedor de associação ofereça acesso à sua implementação interna (com base no código ASP.NET 1.x existente) de forma que o chamador (como as páginas de login ou os controles de segurança do ASP.NET 2.0) não fique preso às especificações dessa implementação.

O padrão adaptador também pode ser usado para reutilizar algum recurso fora de uma classe sem recorrer à herança. Citando Erich Gamma e os demais autores de Design Patterns (Addison-Wesley, 1995), deve-se sempre preferir a composição do objeto em vez da herança. A herança deve ser utilizada principalmente como forma de especializar tipos já existentes para aproveitar o polimorfismo, em vez de como uma estratégia para reutilizar o código já existente. Além disso, em um ambiente de herança única como o .NET Framework, esse padrão ganha importância, pois permite guardar a classe base para outras situações.

A aplicação do padrão adaptador será mais fácil se você organizar melhor seu código ASP.NET 1.x hoje. A organização de toda a sua lógica e dos dados em um grupo de classes só pode ajudar. No mínimo, você pode ter uma classe User que represente o usuário de seu sistema com todas as propriedades esperadas e os comportamentos atribuídos. Além disso, você pode ter uma coleção de objetos User e uma classe de gerência para executar as tarefas CRUD. Dependendo do nível de sofisticação desejado, você também pode ter objetos Password e Role com suas próprias APIs. Não é obrigatório reescrever o código do ASP.NET 1.x na forma de classes, mas isso tornará significativamente mais fácil portar o código para o ASP.NET 2.0.

Conclusão

A API Membership do ASP.NET 2.0 fornece um modelo extensível para construir sua própria camada de validação para o tratamento de credenciais do usuário. Isso é uma grande vantagem porque você não fica limitado a utilizar um determinado esquema e armazenamento de dados. Além disso, existe um conjunto de novos controles de servidor disponíveis para simplificar a criação de interfaces de usuário relativas à segurança (veja a barra lateral em "Controles de segurança no ASP.NET 2.0" para obter mais informações).

O modelo de provedor do ASP.NET 2.0 (uma implementação do padrão de estratégia) oferece uma excelente maneira de evitar ter de refazer a arquitetura da soluções já existentes. Aplicado à associação, o modelo do provedor permite que as páginas e os controles de segurança ASP.NET sejam conectados a componentes personalizados que forneçam interfaces predefinidas. Aplicando o padrão do adaptador, você pode usar uma classe existente, geralmente o ponto de entrada do seu sistema de associação do ASP.NET 1.x, e adaptá-la para expor qualquer elemento interno utilizando a interface padrão do ASP.NET 2.0. Dessa forma, você pode conectar seu código e armazenamento de dados antigos ao excitante mundo novo do ASP.NET 2.0. E o melhor de tudo é que você tem os novos recursos (como controles de segurança, APIs padrão e integração com a ferramenta Web Site Administration) mas ainda pode reutilizar a maior parte do seu código antigo.

Dino Esposito é um dos mentores da Solid Quality Learning e o autor de Programming Microsoft ASP.NET 2.0 (Microsoft Press, 2005). Morando na Itália, Dino é um orador freqüente em eventos dessa área em todo o mundo. Entre em contato com Dino em cutting@microsoft.com ou pelo blog weblogs.asp.net/despos.

Andrea Saltarello é diretor técnico e arquiteto chefe de software na Managed Designs. Ele é MVP em ASP.NET e líder do .NET User Group na Itália. Leia seu blog em blogs.ugidotnet.org.

Mostrar: