Pergunta

Dados I loja de usuário em uma tabela MSSQL chamados Usuários. O que eu quero é ter todos os dados do usuário, acessíveis para o usuário realmente conectado (e-mail, endereço, telefone, se o usuário for assinante etc.).

Eu não quero usar perfis então eu decidi usar MembershipProvider personalizado (ou você sabe alguma maneira melhor, menos dolorosa?).

O que eu não entendo é MembershipUser e membros. Se eu inherite de MembershipProvider, em métodos anulado I controlar dados de acesso de e para o banco de dados.

Mas como faço para usar a classe herdada de MembershipProvider? Se eu quiser autenticar usuário usando associação, que devo fazer:

if(Membership.ValidateUser(string username, string password))
{
   FormsAuthentication.RedirectFromLoginPage(string username, string password);
}

Mas onde é classe herdada de MembershipProvider? E quando usar uma classe herdada de MembershipUser? E o que é a relação entre a associação e MembershipProvider?

Foi útil?

Solução

Embora não seja claro como cristal no MSDN , não é tudo que complicado. Há um trio de classes:

  • Associação: fornece métodos de utilitário e um ponto de entrada - basicamente um Singleton (classe estática).
  • MembershipProvider:. Atua como um assessor de dados e fábrica para MembershipUser objetos
  • MembershipUser:. Representa um usuário individual

A MembershipProvider personalizado é selecionado (por código em associação) com base na configuração do seu aplicativo: configuration / system.web / membership. Aqui é onde você trazer o seu provedor em jogo. Sua implementação MembershipProvider deve ser escrito para acesso todos os dados armazenar sua preferência para os usuários: a sua tabela de usuário neste caso.

objetos MembershipUser só são criadas através de seu MembershipProvider. O método MembershipProvider.ValidateUser () deve verificar contra seus dados armazenar que a combinação de usuário / senha é válida. O MembershipProvider.GetUser () recupera informações do usuário - usá-lo dentro de uma página de acesso protegido e passar System.Web.HttpContext.Current.User.Identity.Name como o usuário autenticado atual.

Isto dito, eu espero que você esteja certo de que você não quer usar perfis , e realmente quer ter uma tabela de usuário separada. Se você estiver escrevendo um aplicativo interno, usando um existente Active Directory ou LDAP habilitado armazenamento de dados iria reduzir os custos de administração e, provavelmente, os riscos de segurança. Há centenas de coisas que você pode facilmente fazer errado quando vai a rota MembershipProvider. Você usa salgados hashes ? Como você está protegendo a tabela do usuário contra a manipulação? MSDN abrange apenas uma fração do questões de segurança você pode enfrentar.

Outras dicas

O provedor específico usado é controlado no web.config. Você pode realmente definir mais de 1 provedor, e ter um padrão. Check: http://msdn.microsoft.com/en-us/library/ 6e9y4s5t.aspx .

Quando chamado assim, a adesão só usa o provedor padrão. Você herdaria MembershipUser, se você quiser fornecer informações adicionais para o usuário, mas que vai amarrar o resto do seu código ao seu provedor específico.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top