Должен ли я использовать имя пользователя или идентификатор пользователя, чтобы ссылаться на проверку подлинности пользователей в ASP.NET

голоса
27

Так что в моем простом сайте обучения, я использую встроенный в ASP.NET систему аутентификации.

Я добавляю теперь таблицу пользователей, чтобы сохранить такие вещи, как его почтовый индекс, DOB и т.д. Мой вопрос:

  1. В новой таблице, должны быть ключом имя пользователя (строки) или идентификатор пользователя , который является то , что GUID глядя числа они используют в asp_ tables.
  2. Если лучшая практика использовать эту уродливую GUID, кто - нибудь знает , как его получить? это , кажется, не будет доступен так же легко , как имя ( System.Web.HttpContext.Current.User.Identity.Name)
  3. Если вы предлагаете мне использовать ни (не справ ни полей имя_пользователя, предоставляемые аутентификации ASP.NET), то как я могу это сделать с помощью проверки подлинности ASP.NET? Один из вариантов мне нравится использовать адрес электронной почты пользователя в качестве входа, но как я сделать систему аутентификации ASP.NET использовать адрес электронной почты, а не имя пользователя? (Или нет ничего, чтобы сделать там, это просто я не решил, что «знать» имя_пользователь на самом деле является адрес электронной почты?

Пожалуйста, обратите внимание:

  • Я не спрашиваю о том , как получить идентификатор GUID в .NET, я только со ссылкой на колонку USERID в asp_ tablesкачестве справ.
  • Имя пользователя является уникальным в подлинности ASP.NET.
Задан 07/08/2008 в 17:19
источник пользователем
На других языках...                            


12 ответов

голоса
31

Вы должны использовать некоторые уникальный идентификатор, либо GUID вы говорите или какой-либо другой автогенерируемая ключ. Однако это число не должно быть видно пользователю.

Огромное преимущество этого является то, что весь ваш код может работать на идентификатор пользователя, но имя пользователя не очень привязана к нему. Затем пользователь может изменить свое имя (которое я нашел полезным на сайтах). Это особенно полезно, если вы используете адрес электронной почты, как логин пользователя ... что очень удобно для пользователей (то они не должны помнить 20 идентификаторов в случае их общий идентификатор пользователя является популярным).

Ответил 07/08/2008 в 17:26
источник пользователем

голоса
23

Вы должны использовать UserID. Это свойство ProviderUserKey из MembershipUser.

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Ответил 07/08/2008 в 18:55
источник пользователем

голоса
12

Я хотел бы предложить, используя имя пользователя в качестве первичного ключа в таблице, если имя пользователя будет уникальным, есть несколько хороших причин, чтобы сделать это:

  1. Первичный ключ будет кластерный индекс и, таким образом, поиск деталей; пользователей через их имя пользователя будет очень быстро.
  2. Это остановит повторяющиеся имена пользователей от появления
  3. Вам не придется беспокоиться об использовании двух различных peices информации (имя пользователя или GUID)
  4. Это сделает написание кода намного проще, так как не имея для поиска два бита информации.
Ответил 07/08/2008 в 18:56
источник пользователем

голоса
5

Я хотел бы использовать идент. Если вы хотите использовать имя пользователя, вы собираетесь сделать «изменить имя пользователя» особенность очень дорого.

Ответил 07/08/2008 в 19:25
источник пользователем

голоса
3

Это старое, но я просто хочу, чтобы люди, которые считают это отметить несколько вещей:

  1. База данных членов САШ оптимизирована, когда речь идет о доступе к записи пользователей. Кластерный индекс искать (оптимальный) в SQL-сервер используется, когда запись выполняется поиск с помощью loweredusername и ApplicationID. Это делает много смысла, как мы только прилагаемое имя пользователя, чтобы пойти, когда пользователь впервые отправляет свои учетные данные.

  2. Справ Идентификатор_пользователя даст больший размер индекса, чем в междунар, но это не очень важно, потому что мы часто извлекать только 1 запись (пользователя) в то время, так и с точки зрения фрагментации, количество прочтений обычно greately перевешивает число записей и правок к таблице пользователей - люди просто не обновлять эту информацию обо всем, что часто.

  3. сценарий regsql, который создает членство таблицы в сети САШ может быть отредактирован так, что вместо того, чтобы использовать NEWID по умолчанию для идентификатора пользователя, он может использовать NEWSEQUENTIALID (), которая обеспечивает более высокую производительность (я профилированное это).

  4. Профиль. Кто-то создает «новый веб-сайт обучения» не следует пытаться изобретать велосипед. Один из сайтов, с которыми я работал в течение Использовали отказа от коробочной версии членских САШ таблиц (за исключением ужасной системы профилей) и таблиц пользователей содержали около 2 миллионов записей пользователей. Даже с таким большим количеством записей, выбирает по-прежнему быстро, потому что, как я сказал, чтобы начать с того, что индексы базы данных сосредоточиться на loweredusername + ApplicationID к peform кластерный индекс искать для этих записей и, вообще говоря, если SQL делает кластерный индекс искать найти 1 запись, у вас нет никаких проблем, даже с огромным количеством записей, при условии, что вы не добавить столбцы в таблицы и начать отходило слишком много данных.

  5. Беспокоясь о GUID в этой системе, мне, на основе фактических результатов и опыта системы, является преждевременной оптимизацией. Если у вас есть Int для идентификатора пользователя, но система выполняет суб-оптимальные запросы из вашего пользовательского индекса дизайна и т.д. системы не будет масштабироваться хорошо. Ребята Microsoft проделали хорошую работу, как правило, с членством САШ дб и есть много более продуктивных вещей, чтобы сосредоточиться на чем изменение USERID к междунар.

Ответил 02/02/2012 в 13:01
источник пользователем

голоса
3

Я бы сказал Используйте UserID так Usernames все еще может быть изменен без влияния на первичный ключ. Я хотел бы также установить столбец имени пользователя должна быть уникальными, чтобы остановить повторяющиеся имена пользователей.

Если вы в основном будет поиск по имени пользователя, а не UserID затем сделать Имя пользователя кластерный индекс и установить первичный ключ, чтобы быть не сгруппированы. Это даст вам быстрый доступ при поиске имен пользователей, однако если вы будете в основном поиске UserIds затем оставить это в качестве кластерного индекса.

Edit: Это также будет соответствовать лучше с текущими членскими таблиц ASP.Net, как они также используют UserID в качестве первичного ключа.

Ответил 06/05/2009 в 09:04
источник пользователем

голоса
3

Я согласен с Palmsey, хотя, кажется, маленькая ошибка в его коде:

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

должно быть

Guid UserID = new Guid(Membership.GetUser(User.Identity.Name).ProviderUserKey.ToString());
Ответил 06/05/2009 в 08:58
источник пользователем

голоса
2

Я хотел бы использовать автоматическое увеличивающееся число обычно Int.

Вы хотите, чтобы сохранить размер ключа как можно меньше. Это держит ваш индекс малого и выгоды внешних ключей, а также. Additonally вы не плотно сцепление дизайна данных к внешним данным пользователя (это справедливо для САШ GUID, а).

Обычно идентификаторы GUID не делают хорошие первичные ключи, поскольку они являются большими и вставки могут произойти на потенциально любой странице данных в таблице, а не на последней странице данных. Основным исключением является ситуация, когда вы работаете mutilple повторены базы данных. GUID, очень полезны для ключей в этом сценарии, но я предполагаю, что у вас есть только одна база данных, так что это не проблема.

Ответил 27/08/2008 в 09:16
источник пользователем

голоса
1

Если вы собираетесь использовать LinqToSql для развития, я бы рекомендовал использовать в Int в качестве первичного ключа. У меня было много вопросов, когда я отношения построены от полей, не Int, даже если поле NVARCHAR (х) имели ограничения, чтобы сделать его уникальным полем.

Я не уверен, если это известная ошибка в LinqToSql или что, но я имел проблемы с ним на текущем проекте, и мне пришлось поменять и первичные ключи FKs на нескольких столах.

Ответил 08/08/2008 в 01:50
источник пользователем

голоса
0

Я хотел бы использовать Guid в моем коде, и, как уже упоминалось адрес электронной почты в качестве имени пользователя. Это, в конце концов, уже уникальным и запоминающимся для пользователя. Может быть, даже канавы идентификатора (v. Спорна).

Кто-то упоминал об использовании кластерного индекса на GUID, если это используется в коде. Я хотел бы избежать этого, особенно если ВСТАВИТЬ ИГНОРИРУЙТЕ s высоки; индекс будет перестроен каждый раз, когда вы вставляете IGNORE записи. Кластерные индексы хорошо работают на идентификаторы автоматического приращения, хотя, потому что новые записи добавляются только.

Ответил 06/05/2009 в 09:48
источник пользователем

голоса
0

Я согласен с Майком Стоуном также. Моя компания недавно внедрила новую пользовательскую таблицу для внешних клиентов (в отличие от внутренних пользователей, которые проходят проверку подлинности через LDAP). Для внешних пользователей, мы решили хранить GUID в качестве первичного ключа, и сохранить имя пользователя в качестве VARCHAR с уникальными ограничениями на поле имени пользователя.

Кроме того, если вы собираетесь хранить в поле пароля, я настоятельно рекомендую хранить пароль в виде соленых, перемешанный бинарного в базе данных. Таким образом, если кто-то взломать вашу базу данных, они не имеют доступа к паролям вашего клиента.

Ответил 08/08/2008 в 02:56
источник пользователем

голоса
0

Я согласен с Майком Стоуном. Я также хотел бы предложить только с помощью GUID в случае, если вы собираетесь быть отслеживание огромного количества данных. В противном случае, столбец простого автоматической инкрементации целое (Id) будет достаточно.

Если вы нуждаетесь в GUID, .NET достаточно хорош, что вы можете получить один от простого ...

Dim guidProduct As Guid = Guid.NewGuid()

или

Guid guidProduct = Guid.NewGuid();
Ответил 07/08/2008 в 17:38
источник пользователем

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