Controle de Usuários - Providers

Ola Carlos,   Seguinte, como pode ter notado, o recurso membership com providers do .net é bem fácil de utilizar, ja cria as tabelas, controla autenticação, recursos para troca de senha, gravação da senha em diferentes configurações de criptografia e etc.. mas também é bem "engessado" não possibilitando sua customização ou mesmo implentação de novas funcionalidades.   Ja construir um recurso destes a mão, é bem mais custoso e levará mais tempo.   Você precisa avaliar o que realmente precisa. Já que mencionou algo de Fazer um Framework para isto, talvez o nome correto não seja um Framework, já que tem somente esta funcionalidade, mas ser um Template ou somente uma DLL mesmo, do qual vc utilz-se somente seus métodos.   Caso esta funcionalidade seja somente para um projeto, aconselho vc usar Providers mesmo,  vai ganhar tempo. Mas caso queira um recurso para ser utilizado em vários projetos, indico a você construir um a mão mesmo. A partir da estaca zero. Se você resolve implementar sua própria autenticação, passando sobre o modelo do ASP.NET, você teria que re-implementar tudo isso ou perder todos os recursos de segurança por exemplo. Mesmo que você considere que não precisa deles hoje, basta desliga-los e eles estarão lá para quando precisar deles, o que é diferente de você implementar uma autenticação personalizada, onde você tem um grande trabalho para perder recursos. Além disso, mesmos nos casos extremos quando a estrutura de dados personalizada precisa ser criada, cria-se um membershipprovider e roleprovider personalizados. Isso porque a autenticação e autorização estão vinculadas a muito recursos, tal como o sitemap, que pode esconder elementos do site se o usuário não tiver permissão de vê-los, a configuração de autorização nos arquivos .config e verificação de grupo dos usuários com isInRole. Normalmente o que leva muitos a acreditarem que precisam de uma autenticação personalizada é terem uma tabela de usuários com dados como nome, endereço, telefone, sobre a qual desejam manter o controle. A questão é que o ASP.NET introduziu um conceito adicional na modelagem dos dados de autenticação : justamente o conceito de dados de autenticação separados de dados de negócio. As tabelas do ASP.NET não vão guardar seus dados e as suas tabelas não precisam guardar dados de autenticação (última vez que o usuário se logou, quantas vezes errou a digitação da senha, horário do último erro de digitação da senha, formato da senha, etc.). Uma boa forma de trabalhar, é utilizar os dados de autenticação do próprio ASP.NET, com seu modelo de dados padrão, fazendo um "vinculo virtual" com sua tabela de usuários. Quer dizer, utilize o createUserWizard para ao mesmo tempo criar o usuário de autenticação do ASP.NET e criar seu usuário em seu banco de dados com os dados de negócio de que precisa. Resumindo : Não vale a pena personalizar o MembershipProvider, utilize-o, personalize a interface em um createuserwizard na hora de criar o usuário. Isto dá para fazer... Mas lembre-se de mensurar tempo x fucionalidade real para este recurso.   Abraços Att   Luiz Maia

Amigo, Caso seja de seu interesse, aqui no site da DevMedia, são disponibilizados Cursos com video aulas bastante intuitivas sobre Membership Providers. Caso opte por Membership, posso ver se consigo acesso gratuito a estes cursos para você, ok?   Apenas me avise...   Abraços e sucesso no projeto!   Att
Luiz Maia

Olá Luiz,   Sim sim, eu gostaria de ter acesso a estes vídeos/cursos que você mencionou para os providers. Você identificou a palavra adequada, o que preciso desenvolver é um template, para que a equipe faça uso do mesmo para aumentar a produtividade no desenvolvimento de algumas coisas em comuns em todos os projetos, como por exemplo, controle de usuários. Se você conseguir disponibilizar algo neste sentido para eu ter acesso, fico agradecido.   Eu li seu post a respeito da utilização dos providers para um ou vários projetos. Realmente, o que precisa ser feito são para vários projetos, a equipe aqui de .NET é júnior (ou em alguns casos, nem isso), e pelo que vi em projetos anteriores, a tela de usuários contém algumas informações a mais do que usuário e senha, como por exemplo perfil de usuário (podendo ser selecionado mais de um perfil). As vezes pode conter informações de endereço, e por ai vai. Eu vi pelo objeto CreateUserWizard que é possível customizar os controles dentro dele, isto é, acrescentar controles, mudar a interface (só não sei se os controles que são inseridos na criação do objeto podem ter os nomes alterados, como ID de um textbox ou coisa semelhante) através do ContentTemplate. Só não sei se a gravação de dados além dos sugeridos pelo controle se é feito a gravação no evento CreatedUser para sua tabela personalizada.   Outra coisa que conta é o tempo. Acho que consigo no máximo 3 semanas para desenvolver este template, isto que tem ainda para eu ver que usuário de uma determinada área não podem acessar outra área (tipo, quando você faz aquela jogada no web.config com roles para dar permissão para acesso a pasta/páginas conforme perfil de usuários?),  controle de perfil, registro de acessos das páginas (obter IP, usuário que acessou, a URL que foi utilizada), controle de erros (estou pensando inicialmente utilizar o Enterprise Library para isso) e controle de menu (to vendo se consigo fazer isso com aquele objeto skmMenu, sabe?). Então, para fazer tudo isso, estou preocupado se o tempo que tenho é suficiente para utilizar os providers, e depois deste template, a empresa espera que para estes itens leve apenas 1 dia para atender o projeto, isto é, querem que seja apenas alterado a interface, coisas desse tipo.   Nas minhas pesquisas, eu vi este artigo do Fabio Galante Mans, http://www.aspneti.com.br/Customizando+o+Membership+e+Role+Provider+344,0.aspx, que acredito que menciona o que você comentou de fazer um vínculo virtual entre as tabelas no banco de dados. Estou certo em pensar seguir este caminho, ou você teria uma outra idéia em relação a minha situação?   Obrigado!

Carlos,   Acho este caminho uma boa. Pode ir sem medo!!! Aconselho também piamante o uso do Enterprise Library 4.1... não aconselho Linq, EDM e etc...   Outra coisa, dependendo do nivel de abstração que você deseja para o gerenciamento de Perfil, você precisará criar um template a mão mesmo. Por exemplo, se deseja gerenciar não somente acesso a paginas, mas também por exemplo Botões e ImageBotoes, terá que construi algo diferente. Manual mesmo.   Por exemplo, numa pagina podem ter acesso varios Perfis, mas somente alguns perfis podem clicar no botão "novo", por exemplo. Neste caso, você tera que construir um sistema de perfil inteiro, dando acesso de Leitura, Escrita ou Nenhum para cada item e cada página.   ps: Vou pedir liberação de creditos para você adquirir o curso, ok?   Abraços Att Luiz Maia

Ah maravilha, muito obrigado pela força!   É, eu acredito que se for necessário aprofundar esse gerenciamento, posso fazê-lo até em uma segunda etapa, algo como melhorar o template, permiter realizar esse tipo de gerenciamento. Bem, neste caso, eu vou fazer da maneira como você mencionou, irei seguir o artigo, customizar o template do createuserwizard e ver se consigo realizar um bom trabalho para implementar nos projetos.   Caso desejar, pode finalizar este chamado, e muito obrigado pela sua atenção! Valeu por esclarecer as dúvidas!   Até mais

Valeu Carlos. Qualquer dúvida estamos a disposição.   Abraços e sucesso no projeto!   Att Luiz Maia