Devo usar o nome de usuário ou ID do usuário para fazer referência a usuários autenticados em ASP.NET

votos
27

Então, na minha website de aprendizagem simples, eu uso o construído em ASP.NET sistema de autenticação.

Estou adicionando agora uma tabela de usuário para salvar o material como seu zip, DOB etc. A minha pergunta é:

  1. Na nova tabela, deve a chave ser o nome de usuário (a string) ou o ID do usuário que é que GUID número olhar eles usam no asp_ tables.
  2. Se a melhor prática é usar esse guid feio, alguém sabe como obtê-lo? parece não estar acessíveis tão facilmente como o nome ( System.Web.HttpContext.Current.User.Identity.Name)
  3. Se você sugere que eu uso não (não o guid nem os campos username fornecido pela autenticação ASP.NET), então como posso fazê-lo com a autenticação do ASP.NET? Uma opção que eu gosto é usar o endereço de email do usuário como login, mas como eu faço sistema de autenticação ASP.NET usar um endereço de e-mail em vez de um nome de usuário? (Ou não há nada para fazer lá, é só me decidir eu saber userName é realmente um endereço de e-mail?

Observe:

  • Não estou pedindo sobre como obter um GUID em .NET, eu me refiro apenas à coluna userID na asp_ tablescomo guid.
  • O nome de usuário é único na autenticação ASP.NET.
Publicado 07/08/2008 em 17:19
fonte usuário
Em outras línguas...                            


12 respostas

votos
31

Você deve usar algum ID único, o GUID que você menciona ou algum outro auto chave gerada. No entanto, este número não deve ser visível para o usuário.

A grande vantagem disso é que todo o seu código pode trabalhar na identificação de usuário, mas o nome do usuário não está realmente ligada a ele. Em seguida, o usuário pode alterar o seu nome (que eu tenha encontrado útil em sites). Isto é especialmente útil se você usar o endereço de e-mail como login do usuário ... o que é muito conveniente para os usuários (então eles não tem que lembrar 20 IDs no caso de sua ID de usuário comum é um popular).

Respondeu 07/08/2008 em 17:26
fonte usuário

votos
23

Você deve usar o UserID. É a propriedade ProviderUserKey de MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Respondeu 07/08/2008 em 18:55
fonte usuário

votos
12

Sugiro usar o nome de usuário como a chave primária na tabela se o usuário vai ser única, existem algumas boas razões para fazer isso:

  1. A chave principal será um índice agrupado e, assim, procurar um usuários detalhes através do seu nome de usuário será muito rápido.
  2. Ele vai parar nomes de usuário duplicados apareçam
  3. Você não tem que se preocupar usando dois pedaços diferentes de informação (nome de usuário ou guid)
  4. Isso fará com que escrever código muito mais fácil porque de não ter que pesquisar dois bits de informação.
Respondeu 07/08/2008 em 18:56
fonte usuário

votos
5

Gostaria de usar um ID de usuário. Se você quiser usar um nome de usuário, você está indo para fazer o recurso de "mudar o nome de usuário" muito caro.

Respondeu 07/08/2008 em 19:25
fonte usuário

votos
3

Esta é antiga, mas eu só quero que as pessoas que acham que este notar algumas coisas:

  1. O banco de dados associação aspnet é otimizado quando se trata de acessar os registros do usuário. O índice agrupado procurar (ideal) no sql server é utilizado quando um registro é procurado utilizando loweredusername e ApplicationId. Isto faz muito sentido, já que só tem o nome de usuário fornecido para ir em frente quando o primeiro usuário envia suas credenciais.

  2. O ID de usuário guid dará um tamanho índice maior do que um int, mas isso não é realmente importante porque, muitas vezes, recuperar somente 1 registro (usuário) em um tempo e em termos de fragmentação, o número de leituras normalmente greately supera o número de gravações e edições para uma tabela de usuários - as pessoas simplesmente não atualizar essa informação tudo o que muitas vezes.

  3. o script regsql que cria as tabelas de associação ASPNET podem ser editados de modo que em vez de usar NEWID como padrão para ID de usuário, ele pode usar NEWSEQUENTIALID () que proporciona melhor desempenho (eu tenho perfilado isso).

  4. Perfil. Alguém a criação de um "novo site de aprendizagem" não deve tentar reinventar a roda. Um dos sites que eu trabalhei para usado um fora da versão caixa das tabelas de associação aspnet (excluindo o sistema de perfil horrível) e tabela de usuários continha quase 2 milhões de registros do usuário. Mesmo com um número tão elevado de registros, seleciona ainda estavam rápido, porque, como eu disse, para começar, os índices de banco de dados se concentrar em loweredusername + ApplicationId que efetuar índice agrupado procurar por esses registros e de um modo geral, se o SQL está fazendo um índice agrupado procurar para encontrar um registro, você não tem quaisquer problemas, mesmo com um grande número de registros, desde que você não adicionar colunas para as mesas e começar a puxar para trás muitos dados.

  5. Preocupar-se com um guid neste sistema, para mim, com base no desempenho e experiência do sistema actual, é otimização prematura. Se você tem um int para o seu ID de usuário, mas o sistema executa consultas sub-ótimas por causa de seu projeto índice personalizado etc. o sistema não escala bem. Os caras da Microsoft fez um bom trabalho em geral com a db associação aspnet e há muitas coisas mais produtivas para se concentrar em que mudar userId para int.

Respondeu 02/02/2012 em 13:01
fonte usuário

votos
3

Eu diria que o uso da UserID tão nicks ainda pode ser alterado sem afetar a chave primária. Também gostaria de definir a coluna nome de usuário para ser exclusivo para parar de nomes de usuários duplicados.

Se você vai, principalmente, estar procurando no nome de usuário em vez de UserID depois fazer usuário um índice agrupado e definir a chave primária a ser não agrupado. Isto lhe dará o acesso mais rápido ao procurar por nomes de usuário, se, contudo, você será principalmente à procura de UserIds em seguida, deixar isso como o índice de cluster.

Edit: Isso também irá encaixar melhor com as tabelas atuais de associação do ASP.NET como eles também usam o UserID como chave primária.

Respondeu 06/05/2009 em 09:04
fonte usuário

votos
3

Concordo com Palmsey, embora não parece ser um pequeno erro em seu código:

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name)).ProviderUserKey.ToString());

deveria estar

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Respondeu 06/05/2009 em 08:58
fonte usuário

votos
2

Gostaria de usar um número de auto incremento geralmente um int.

Você quer manter o tamanho da chave de tão pequeno quanto possível. Isso mantém o seu índice de pequeno e beneficia todas as chaves estrangeiras também. Associado a isto você não está firmemente acoplamento do projeto de dados para dados de usuários externos (isto é válido para o aspnet GUID também).

Geralmente GUIDs não fazem bons chaves primárias como eles são grandes e inserções pode acontecer a potencialmente qualquer página de dados dentro da tabela em vez de na última página de dados. A principal exceção a isso é se você estiver executando bancos de dados mutilple replicados. GUIDs são muito úteis para as chaves neste cenário, mas eu estou supondo que você só tem um banco de dados de modo que este não é um problema.

Respondeu 27/08/2008 em 09:16
fonte usuário

votos
1

Se você está indo estar usando LinqToSql para o desenvolvimento, eu recomendo usar um int como uma chave primária. Eu tive muitos problemas quando eu tinha relações construído fora dos campos não-Int, mesmo quando o campo nvarchar (x) tinha restrições para torná-lo um campo único.

Eu não tenho certeza se este é um bug conhecido em LinqToSql ou o que, mas eu tive problemas com ele em um projeto atual e eu tive que trocar PKs e FKS em várias tabelas.

Respondeu 08/08/2008 em 01:50
fonte usuário

votos
0

Gostaria de usar o GUID no meu código e como já mencionado um endereço de e-mail como nome de usuário. É, afinal, já única e memorável para o usuário. Talvez até mesmo abandonar o guid (v. Discutível).

Alguém mencionou usando um índice agrupado na GUID se este estava a ser usado em seu código. Quero evitar este, especialmente se INSERIR IGNORE s são elevados; o índice será recriado cada vez que você inserir ignorar um recorde. índices agrupados funcionam bem em IDs auto incremento embora porque novos registros só são anexados.

Respondeu 06/05/2009 em 09:48
fonte usuário

votos
0

Eu estou concordando com Mike Stone também. Minha empresa implementou recentemente uma nova tabela de usuário para clientes externos (em oposição a usuários internos que autenticar através de LDAP). Para os usuários externos, optou-se armazenar o GUID como chave primária, e armazenar o nome de usuário como varchar com restrições exclusivas no campo nome de usuário.

Além disso, se você está indo para armazenar o campo de senha, eu recomendo guardar a senha como um salgado, hash binário no banco de dados. Dessa forma, se alguém invadir seu banco de dados, eles não têm acesso a senhas do seu cliente.

Respondeu 08/08/2008 em 02:56
fonte usuário

votos
0

Concordo com Mike Stone. Também gostaria de apenas sugerir usando um GUID no evento que você está indo para estar acompanhando uma enorme quantidade de dados. Caso contrário, uma coluna simples inteiro auto incrementado (Id) será suficiente.

Se você precisa fazer o GUID, .NET é lindo o suficiente para que você pode obter um por um simples ...

Dim guidProduct As Guid = Guid.NewGuid()

ou

Guid guidProduct = Guid.NewGuid();
Respondeu 07/08/2008 em 17:38
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more