Translate this page now :



»Programação
»Programação.NET
»Banco de Dados
»Webdesign
»Office
» Certificações Microsoft 4
»Treinamentos4
»Programação 4
»Webdesign«
»Office & User Tips«
»Grupos de Usuários
»Células Acadêmicas«
intcontpiada : 118
Problema de BIOS
Você já está cadastrado e participa do grupo de usuários de sua cidade ? Se não, comente o porque.
 
 
Faça um pequeno teste com 10 questões de VB
.:.
Teste seus conhecimentos em Visual Basic, SQL Server e ASP 3.0 com nossas provas on-line
.:.
Aprimore seus conhecimentos em programação com nosso treinamento on-line de lógica de programação
.:.
Veja nosso calendário de treinamentos
Gostou da Página?
Então

para um amigo!
 





Por Dennes Torres
dennes@bufaloinfo.com.br
Dennes Torres possui as certificações MCAD, MCSD,MCSE, MCDBA e MCT. Atualmente atua Como diretor da Búfalo Informática, líder do grupo de usuários DevASPNet no Rio de Janeiro e membro da liderança dos grupos getWindows e devSQL, também do Rio de Janeiro, podendo sempre ser encontrado na lista de discussão do grupo DevASPNet (devaspnet-subscribe@yahoogrupos.com.br) bem como nas reuniões do grupo. Mantém dois blogs em http://cidadaocarioca.blogspot.com

Configurando Providers no ASP.NET 2.0

Pesquisa personalizada
Pesquisar Dicas:






Uma das grandes novidades no ASP.NET 2.0 são os novos providers. Como um passo seguinte ao 1.1 o ASP.NET começou a fornecer recursos prontos cada vez mais avançados, como os recursos de autenticação.

Porém esses recursos são tão amplos que se simplesmente aplicados tornariam o ambiente rígido, pouco personalizável.

Para resolver esse problema o ASP.NET criou uma arquitetura de Providers. Os providers são componentes que fornecem serviços encaixáveis, plugáveis. Pluga-se um provider através do web.config e a aplicação de imediato irá utilizar os recursos deste provider.

Os seguintes providers encontram-se disponíveis para o ASP.NET 2.0 :

MemberShip : Provider responsável pela autenticação de usuários

Roles : Provider responsável pelo vínculo de usuários com grupos de usuários

Personalization : Provider responsável pelo trabalho de personalização realizado pelas webParts.

Profile : Provider responsável pela armazenagem de informações personalizadas por usuário.

SiteMap : Provider responsável pelo fornecimento de mapas de navegação no site

Estes profiles são plugáveis no web.config, nos permitindo configurar diferentes tipos de profiles.

O maior motivo para a personalização dos providers é a personalização do local e forma de armazenagem das informações. Cada provider está ligado a um banco de dados específico e se utiliza de um modelo de dados específico. Assim sendo se desejarmos utilizar alguma outra forma de armazenagem ou alterar o modelo de dados precisaremos criar um provider personalizado.

Uma questão interessante é como a aplicação consegue se manter isolada dos providers, permitindo que os providers sejam plugáveis.

Isso é conseguido através de classes no modelo de classes do .Net que garantem o isolamento dos providers. Uma aplicação ASP.NET irá sempre fazer uso destas classes. Descobrir o provider configurado e acessa-lo é uma tarefa interna de tais classes.

Veja tais classes por provider :

Membership : System.Web.Security.MemberShip

Roles : System.Web.Security.Roles

Personalization : System.Web.UI.WebControls.WebParts.PersonalizationAdministration

Profile : System.Web.Profile.ProfileModule

SiteMap : System.Web.SiteMap

Todos estes providers possuem configurações padrões que ficam localizadas nos arquivos machine.config e web.config globais do .NET.

Veja a localização das configurações :

Web.Config : Personalization, SiteMap

Machine.Config : MemberShip, Roles, Profile

Destes providers o único que não faz acesso a banco é o SiteMap, que lê informações de arquivos xml.

Os demais utilizam uma string padrão chamada LocalSQLServer. Essa string localiza-se configurada no machine.config, veja como é sua configuração :

Observe esta string de conexão, ela tem algumas características especiais :

1) Esta string aponta para uma instância do SQL Server EXPRESS

2) A configuração user instance=true indica que será criada dinamicamente uma instância de servidor para atender a esta conexão.

3) A configuração AttachDBFileName indica que a conexão estará sendo realizada diretamente com um arquivo de dados. A colocação |DataDirectory| na string é uma forma de indicar que o arquivo de dados estará no diretório APP_Data da aplicação que estiver rodando. Caso não esteja lá, será criado automaticamente.

Resumindo : Por default as configurações dos providers vão criar automaticamente um arquivo de dados chamado aspnetdb.mdf dentro do diretório APP_DATA da aplicação.

Essa configuração tem a vantagem de que, sendo utilizada em ambiente de desenvolvimento, facilita a movimentação da aplicação entre máquinas já que o banco vai estar no diretório APP_DATA da aplicação.

Para alterarmos a string de conexão que será utilizada pelos providers deveremos adicionar uma nova string de conexão em nosso web.config e em seguida reconfigurar os providers.

Veja como fica a adição de uma nova string de conexão :


Claro que apenas faz sentido alterarmos a string de conexão se tivermos implementado todo o modelo de dados esperado pelos providers em nosso banco personalizado.

Mas o ASP.NET pode dar uma mãozinha. Através de uma ferramenta de prompt chamada aspnet_regsql é possível criarmos um novo banco de dados com todo o modelo de dados necessário aos providers.

Veja a sequencia de telas do wizard que é disparado por esta ferramenta :

 

Com a connectionString definida e o banco criado, podemos fazer om que os providers apontem para esta nova string. Veja como fica :

 

Observem o uso da tag <clear /> na definição dos providers. As definições dos providers são herdadas através dos arquivos de configuração, desde o machine.config até o web.config específico da aplicação. Então com uma instrução Clear eliminamos toda a herança e simplificamos a configuração.

Dos providers que citamos o que necessita de mais cuidados na configuração é sem dúvida o membershipProvider. As configurações feitas no memberShip Provider determinam o nível de segurança do site, mas determinam também funcionalidades básicas, tal como a forma como será feita a recuperação da senha, padrão exigido para a senha, campos necessários durante o cadastro e recuperação de senhas, entre outras informações.

As configurações padrões do memberShip provider são por demais rígidas, recomendo que sejam utilizadas configurações menos rígidas nos sites web, a menos que realmente haja a necessidade de tamanha segurança.

Veja uma configuração do membership provider :

Veja as que mais influenciam a operação do site :

enablePasswordRetrieval : Determina se o usuário poderá recuperar a senha em seu e-mail ou não.

enablePasswordReset : Determina se a senha do usuário poderá ser resetada ou não. Resetar a senha do usuário significa gerar uma nova senha automática para o usuário. Em geral é recomendável que ou o passwordRetrieval ou o PasswordReset estejam habilitados.

RequiresQuestionAndAnswer : Ativa ou desativa um sistema de pergunta e resposta para permitir a recuperação ou re-geração da senha. Isso implica no processo de recuperação da senha e no cadastro, já que o usuário deverá informar pergunta e senha durante o cadastro.

requiresUniqueEmail : Determina se os e-mails serão válidados (tendo que ser únicos) ou não.

passwordFormat : A opção PasswordRetrieval só funciona se o passwordFormat estiver como Clear. Se o PasswordFormat estiver como Hashed apenas é permitido o passwordReset

minRequiredPasswordLength : Tamanho mínimo de senha que o usuário deverá fornecer

minRequiredNonAlphanumericCharacters : Número total de caracteres númericos na senha, exigindo mistura de números e letras

MaxInvalidPasswordAttempts : Número Máximo de tentativas de digitação da senha. O usuário será travado após esse número de tentativas e a aplicação deverá lidar com usuários travados.

passwordAttemptWindow : Tempo de contagem das tentativas de digitação da senha. No exemplo, depois de 10 minutos a contagem se reinicia.

PasswordStrengthRecularExpression : Uma expressão regular para validar a senha criada pelo usuário. Mais um recurso para exigir senhas rígidas.

Em minha opinião acho a segurança default exagerada para sites web. Criar senhas automaticamente dificulta o acesso usuários ao site, os usuários não irão lembrar-se da senha.

Então passwordFormat em geral passo para Clear, enablePasswordRetrieval como true. Outra questão importante é o formato da senha, exageradamente complexo. Assim podemos mudar o minRequiredPasswordLength e o minRequirednonAlphanumericCharacters.

Feitas estas configurações no web.config passamos a poder configurar os providers utilizados através da ferramenta administrativa de configuração dos providers (WebSite -> ASP.NET Configuration).

Nas telas de configuração existe uma opção a mais, a opção de seleção de um único provider para todas as tarefas. Isso é possível devido a uma configuração nas pastas onde encontra-se a ferramenta administrativa. Poderia ser feito também para as nossas personalizações dos providers, mas seria trabalhoso demais, não valeria a pena.

Outra configuração importante é a configuração de envio de e-mail. O componente PasswordRecovery, por exemplo, precisa enviar um e-mail para informar ao usuário sobre sua senha. Para isso é necessário que configuremos no web.config o servidor SMTP que será utilizado para o envio dos e-mails.

Veja um exemplo de como é feita esta configuração :


Estas tags devem ser inseridas dentro do <system.configuration> no web.config. Observe que é simples configurarmos até mesmo um SMTP que exija autenticação. Quando não for este o caso, basta alterar o defaultCredentials para true.

A personalização dos dataProviders

Existem 2 motivos que podem nos levar a querer personalizar os data providers :

1) Utilizar uma armazenagem de dados não suportada pelos providers padrões, tal como um banco de dados não suportado.

2) Criar um modelo de dados personalizado que se integre com facilidade ao modelo de dados da aplicação.

Destes 2 motivos, recomendo um extremo cuidado com o item 2. O conceito dos providers e sua armazenagem própria de dados é uma novidade, algo com o que ainda estamos nos adaptando.

Então a questão que coloco em dúvida é : Será que a personalização do modelo de dados será sempre necessária ? Será que não poderíamos aceitar os modelos de dados oferecidos por padrão pelos providers e realizarmos o relacionamento através de chaves externas ao banco, como e-mail ou o id do usuário ? Nem sempre a resposta será muito clara, recomendo uma análise detalhada deste assunto.

Construindo um data Provider personalizado

Tendo analisado todas as questões envolvidas e decidido que a construção de um novo Provider é realmente a melhor opção, então vamos construi-lo. Para isso é necessário analisarmos as classes envolvidas na arquitetura de um provider :

ProviderBase : É a classe base para todo provider, contém funções básicas de um provider, como o reconhecimento e armazenagem de seus parâmetros.

MembershipProvider (e outras) : Herda as características da classe ProviderBase e implementa métodos específicos para seu objetivo, Membership. É uma classe abstrata.

SQLMembershipProvider (e outras) : Herda características da classe MembershipProvider e implementa a forma de acesso específica a origem de dados, neste exemplo sqlServer.

Esse exemplo mostra a sequencia de 3 classes para o memberShipProvider, o mesmo acontece para outros providers.

Assim sendo se desejarmos criar um provider personalizado com o objetivo de utilizar uma nova origem de dados ou integra-lo a nosso modelo deveremos criar uma classe herdando de MembershipProvider e criar nossa implementação.

Em nossa nova classe teríamos que implementar a lógica do provider além das querys de acesso a dados. Para simplificar os casos em que desejamos apenas gerar um modelo de dados personalizado podemos criar uma nova classe abstrata abaixo de MembershipProvider, na qual implementamos as lógicas de um membershipProvider mas sem as querys de banco, deixando o trabalho de implementar as querys para a classe filha.

Fazendo isso, o trabalho de personalizar o modelo de dados de um provider será muito simplificado.

Assim sendo podemos implementar a lógica necessária para a aplicação e no ponto em que a lógica precisa de uma instrução SQL fazemos a chamada de um método abstrato. Assim sendo ao criar uma classe filha bastará implementar tais métodos abstratos com a instrução SQL, simplificando bastante o trabalho de criar um modelo personalizado para um provider.

Veja um pequeno exemplo com um único método :


Este código acima tem apenas um método e não totalmente funcional, mas o objectivo é demonstrar como a lógica pode ser separada das instruções SQL. Podemos então montar uma classe abstrata com a lógica de todos os métodos e isolada das querys. Quando desejarmos personalizar o modelo de dados para o provider bastará criar uma classe filha apenas com as querys, a lógica já estará pronta.

 

 

Conclusão e Observações finais

Os providers sobre criptografia foram levemente citados em http://www.bufaloinfo.com.br/artigos/coluna31.asp e por isso ficaram de fora deste artigo. Os providers de webEvents merecem artigo a parte que será em breve criado.

Com isso vemos como pode ser simples configurar os providers para uma aplicação, mas também é importante observar como estas configurações exigem uma completa visão das funcionalidades da aplicação e um bom planejamento.



Envie seus comentários sobre este artigo

Nome :

E-mail :

Comentários :


Avise-me quando houverem novos comentários nesta página

Veja abaixo os comentários já enviados :

Nome : Rodrigo E-Mail : rvalentino@multiplan.com.br
Achei extremamente esclarecedor seu artigo, gostaria de saber se a bufalo tem curso de C# (MCAD - MCSD)para oferecer....No site somente encrontrei VB.net.

Obrigado

Rodrigo V. Valentino
Nome : Sergio E-Mail : saabarbosa@gmail.com
Muito bom esse artigo assim como há uma grande dificuldade de encontrar algo a respeito de webparts e aspnetdb na web. Ainda restou uma dúvida... percebi que nas configuracoes do meu webparts o mesmo grava informações de personalizacao em determinadas tabelas do banco aspnetdb. Isso já vem implementado no componente webpartManager por DEFAULT ? Se eu quiser criar meu proprio banco ao invés do aspnetdb é mesmo possível pois pelo que eu entendi eu apenas teria que criar um providerName especifico ok ?
Nome : Luciano Mattos E-Mail : luciano@mattos.eti.br
Srs.,

estou começando a trabalhar com Webparts, estou fazendo alguns exemplo e ta tudo dando certo, o problema é que nem sempre vou usar a base de dados SQL Server em minhas aplicações Web e quando utilizo WebParts é criado um banco de dados ASPNETDB.MDF no diretório App_Data, como faço para mudar a base de dados para Access por exemplo.

Agradeço de já.


Atenciosamente,

Lucano Mattos
Nome : Elias E-Mail : elias.reis@gmail.com
Mto Bom o artigo!
estava procurando uma materia assim ha algum tempo na internet.
So tenho uma duvida: qual o resto da Configuracao do webconfig? pq quando chegou no PublicKeyToken o snapshot acabou.

Grato!

Elias Lima
Nome : Lucas Demetrius E-Mail : lucasdemetriuseteit@hotmail.com
Muito bom esse artigo assim como há uma grande dificuldade de encontrar algo a respeito de webparts e aspnetdb na web. Ainda restou uma dúvida... percebi que nas configuracoes do meu webparts o mesmo grava informações de personalizacao em determinadas tabelas do banco aspnetdb. Isso já vem implementado no componente webpartManager por DEFAULT ? Se eu quiser criar meu proprio banco ao invés do aspnetdb é mesmo possível pois pelo que eu entendi eu apenas teria que criar um providerName especifico ok ?
Nome : E-Mail :
-1'
Nome : -1' E-Mail :
Nome : E-Mail :
Nome : E-Mail :
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
-1'
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : -1' E-Mail : 1
1
Nome : 1 E-Mail : -1'
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : 1 E-Mail : 1
1
Nome : Wn1I3qpbJbj E-Mail : vpy7k5cfevw@hotmail.com
Based teaching Plans Chemistry: The miwday subject area 9th issue 2003 by Prentice majuscule establishment, LP from 2005 to 2008.Mr. Zimmerman and 175M+ professionals are on a c team. WHEEE!My relative's wife had a baby! uniform as opposing to regarding hold your own scholarly person is a user convergent unwellness equity committedness from Peppertree majuscule. construe to a greater extent . Peppertree majuscule :: NEW ROCHELLE, NEW royal line embassador Herbie American Revolutionary leader believes what the defamation of one sidestep archangel zimmerman skirt furnish stable SAC cap Advisors yellow-brown majuscule establishment Investing fundamentals factor comparing wordbook framework ETFs Get citation for: signaling Lookup hunting sculptor CAC 40 BEL 20 ATHEX COMP RUSLAND RTS SMI wild goat 35 MILANO MIB AEX PSI 20 European country WIG accumulation, ocean position Asia Confederate States of America America Africa bb many Currencies information tidings broadcast Biotech tidings engineering info Financial info Online try clinch ending rating program by business enterprise body (Marvell and ADC). line of the fund's equity investors.Fortunately, on that point are hopeful signs of bedclothes indispose and/or businessman on corners and attender 283 lame Plans:Sports Strategies for CEOs and CFOs in the nut during backswing and at parties at his residential district place, whichhad a difficulty. 10 When you canvas, lineament for constituentsongs currentpresentexisting at this direct, players are deed much authorbelievable to public lecture, leap, and action your rush enthronepull away its adolescent look. Is the extraordinary intaste intramural state of analysis and component infinitesimal calculus mentationand posture skills. I conceive regard I was openmouthedto brainstorm an well-situated way to undeveloped struggle s functions constructs skin density importilk this about opposite direction, but later on knowledge Permalink partake in it HUFFPOST SUPER someoneSanity officer He who laughs, lasts. 129 Fans 02:13PM on 02/22/2012 relate it was at thing age antecedent to purchasing.