Provedor Microsoft Membership Provider Vs personalizado Vs Sistema de Acesso Completo personalizado

Question

Atualmente, estou convertendo um muito de idade, mas trabalhar local ASP clássico para ASP.Net.

Ele tem um sistema de gestão de usuário completamente personalizado escrito. Enquanto isso funciona bem, ele realmente necessita de uma actualização como eu quero que seja mais flexível para alguns projetos futuros nas obras.

Quando perguntei a alguém sobre isso, eles disseram: "Você precisa usar o Provedor Microsoft" e deu uma palestra sobre como a Microsoft liberar todas essas coisas para o bem livre e como eles são e devem ser re usado tanto quanto possível.

Eu fiz um pouco de pesquisa sobre ele (principalmente olhando para os vídeos no http://asp.net/learn ) e estou muito impressionado com algumas das características como parece haver arrastar e soltar componentes para itens que iria me levar séculos para escrita.

No entanto, o banco de dados de membro atual é complicado de explicar, é um banco de dados totalmente personalizado escrito que tem muitas relações internas ... Não é realmente "compatível" com o Microsoft padrão.

Tomei uma olhada Como faço para: Criar um provedor personalizado Membership? , mas sinto um pouco fora da minha zona de conforto e preocupado ele quer ser lenta, introduzir uma falha de segurança ou simplesmente não vai funcionar.

No final do dia, o Microsoft Membership devem trabalhar para mim - os únicos personalizações eu realmente preciso é de login para usar o campo de nome de usuário / senha no meu banco de dados ea criar script de usuário que tem um monte de código personalizado a vários sistemas de terceiros (a necessidade de serviços de prestação etc.).

Eu estava pensando, o que você faria se depara com uma situação semelhante?

1. Use o Microsoft Membership e de alguma forma fazê-lo funcionar para você (embora eu gostaria sugestões)

2. Use o Microsoft Membership Provider mas provedor de uso personalizado que é personalizado em torno de seu código.

3. Use a sua própria solução totalmente personalizada?

Answer 1

Esse vídeo faz as coisas complicar :) Se você estiver indo para implementar um provedor personalizado, em seguida, refletor sobre outra já existente é um bom lugar para começar:)

Como uma opção rápida e suja você poderia, é claro, cortar os procedimentos armazenados que os usos provedor SQL adesão, mas o código personalizado para os serviços de provisão é provavelmente alongamento que.

Se você pensa sobre ele o controle remoto de provisionamento de serviços realmente não pertencem a um provedor de associação, não é realmente uma função de membro - tudo associação faz é fornecer nomes de usuários e senhas e autenticação em torno deles. Minha própria impressão é que você deve mover o provisionamento de serviços fora de lá, e executá-lo no site do ASP.NET depois que um usuário foi criado - mesmo se isso é só chamar um procedimento armazenado uma vez que o provedor de associação tem feito a sua coisa. Se você fizer isso, você pode achar que o provedor de associação SQL vai fazer tudo o que você precisa que ele (provavelmente com as funções e provedores de perfil também), e, portanto, você tem forma menos código para escrever!

Answer 2

Eu estive em situações semelhantes no passado. Em ambos os casos, criamos implementações personalizadas dos prestadores (MembershipProvider, RoleProvider, ProfileProvider) ao redor do mecanismo existente.

Em ambos os casos nós só usamos as implementações de provedor de somente acesso de leitura, por exemplo, para nos dar as gubbins validação fáceis em web.config e afins. O código de administração de usuários ficou bem sozinho como ele funcionou muito bem.

Answer 3

Se as obras provedor existente (tem os campos corretos para seus dados), o uso que para começar. Você pode facilmente substituir esse com um provedor de cliente mais tarde (apenas uma única configuração alteração de valor).

Cuidado não há um "fora da caixa" interface de gerenciamento ASP.NET para isso, você precisa rolar seus próprios ou usar um terceiro partido.

Answer 4

Usar meu MembershipProvider especializados para trabalhar contra as minhas próprias tabelas de banco de dados.