Подтвердить что ты не робот

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

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

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

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

Обратите внимание:

  • Я не спрашиваю, как получить GUID в .NET, я просто ссылаюсь на столбец userID в asp_ tables as guid.
  • Имя пользователя уникально в аутентификации ASP.NET.
4b9b3361

ОТВЕТЫ

Ответ 1

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

  • Первичный ключ будет кластеризованным индексом, и поэтому поиск деталей пользователей через их имя пользователя будет очень быстрым.
  • Это приведет к появлению повторяющихся имен пользователей
  • Вам не нужно беспокоиться об использовании двух разных точек информации (имя пользователя или руководство).
  • Это значительно упростит код записи из-за того, что вам не нужно искать два бита информации.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

Я бы использовал идентификатор пользователя. Если вы хотите использовать имя пользователя, вы очень сильно измените функцию "изменить имя пользователя".

Ответ 5

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

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

должен быть

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

Ответ 6

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

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

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

Ответ 7

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

  • База данных членства aspnet оптимизирована, когда дело доходит до доступа к пользовательским записям. Кластеризованный поиск индекса (оптимальный) в sql-сервере используется, когда поиск выполняется с использованием loweredusername и applicationid. Это имеет большой смысл, поскольку у нас есть только указанное имя пользователя для продолжения, когда пользователь сначала отправляет свои учетные данные.

  • Указатель guidid даст больший размер индекса, чем int, но это не очень важно, потому что мы часто только извлекаем 1 запись (пользователя) за раз и в терминах фрагментации, количество чтений обычно значительно перевешивает количество записей и изменений в таблице пользователей - люди просто не обновляют эту информацию так часто.

  • regsql script, который создает таблицы членства aspnet, может быть отредактирован так, чтобы вместо использования NEWID по умолчанию для userid он может использовать NEWSEQUENTIALID(), который обеспечивает лучшую производительность (я профилировал это).

  • Профиль

    . Кто-то, создающий "новый учебный веб-сайт", не должен пытаться изобретать велосипед. На одном из сайтов, на которых я работал, использовалась некорректная версия таблиц членства aspnet (исключая ужасную систему профилей), а таблица пользователей содержала почти 2 миллиона записей пользователей. Даже при таком большом количестве записей выборки все еще были быстрыми, потому что, как я уже сказал, индексы базы данных фокусируются на loweredusername + applicationid для преобразования скопированного индекса в эти записи и, вообще говоря, если sql выполняет поиск в кластерном индексе чтобы найти 1 запись, у вас нет никаких проблем, даже с огромным количеством записей при условии, что вы не добавляете столбцы в таблицы и начинаете вытягивать слишком много данных.

  • Беспокойство по поводу руководства в этой системе, для меня, исходя из фактической производительности и опыта системы, является преждевременной оптимизацией. Если у вас есть int для вашего идентификатора пользователя, но система выполняет субоптимальные запросы из-за вашего пользовательского дизайна индекса и т.д. Система не будет хорошо масштабироваться. Ребята из Microsoft сделали в целом хорошую работу с членством в aspnet db, и есть много более продуктивных вещей, на которые нужно сосредоточиться, чем изменение userId на int.

Ответ 8

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

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

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

Ответ 9

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

Я не уверен, что это известная ошибка в LinqToSql или что-то, но у меня были проблемы с ней в текущем проекте, и мне пришлось менять PK и FK на несколько таблиц.

Ответ 10

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

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

Dim guidProduct As Guid = Guid.NewGuid()

или

Guid guidProduct = Guid.NewGuid();

Ответ 11

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

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

Ответ 12

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

Кто-то упомянул об использовании кластерного индекса в GUID, если он использовался в вашем коде. Я бы избегал этого, особенно если ВСТАВКИ высоки; индекс будет перестраиваться каждый раз, когда вы вставляете запись. Кластеризованные индексы хорошо работают с идентификаторами автоматического увеличения, потому что новые записи добавляются только.