Нормализованное имя пользователя ПРОТИВ имени пользователя в ядре DotNet

ProgramBox

Нормализованное имя пользователя ПРОТИВ имени пользователя в ядре DotNet

Post author:admin
Запись опубликована:17 января, 2022
Post category:Вопросы по программированию

#c# #asp.net-core #asp.net-identity

Вопрос:

Я пытаюсь создать пользовательскую реализацию IUserLoginStore для MongoDB и заметил, что при использовании

 UserManager<ApplicationUser>

с помощью метода

  var userResult = await _userManager.CreateAsync(user);

он проходит через реализацию

 GetUserNameAsync
FindByNameAsync
SetNormalizedUserNameAsync
GetUserIdAsync

Я хотел бы прояснить два вопроса:

для чего нужно иметь нормализованное имя пользователя и имя пользователя? единственное отличие, которое я мог заметить, заключается в том, что имя пользователя normalized указано в верхнем регистре.
Я использую свою реализацию только для хранения пользователей с внешнего логина(Google plus), есть ли способ, которым я могу опустить имя пользователя и нормализованное имя пользователя, так как в основном я использую электронную почту в этих трех полях, я чувствую, что дублирую данные, и для меня это не имеет никакого смысла.

есть какие-нибудь рекомендации?

Ответ №1:

1) Нормализация останавливает людей, регистрирующих имена пользователей, которые отличаются только буквенной оболочкой.

2) Нет — эти поля являются частью базовой модели данных.

1. Нет. Боюсь, это полностью в ваших руках.

2. Да, нормализация выполняется для того, чтобы люди не регистрировали имена пользователей, которые отличаются только буквенной оболочкой. Но то, о чем спрашивает ОП, т. Е. «какова цель наличия имени пользователя NormalizedUsername» в базе данных, заключается в том, что это повышает производительность по сравнению с выполнением этого во время выполнения SQL-запроса. Более подробная информация здесь: github.com/aspnet/Identity/issues/351

3. К вашему сведению, по крайней мере, в моем случае с использованием dot net core 3.1 с Asp.Net Основной идентификатор и идентификатор 4, нормализованное имя пользователя должно быть в верхнем регистре. В противном случае вход пользователя в систему завершится ошибкой.

Ответ №2:

Да, вы можете (если действительно хотите):
1. FindByNameAsync следует искать по u.Name без учета регистра (доверяете ли вы настройкам своей базы данных?)
2. GetNormalizedUserNameAsync должен вернуться user.Name.Прописные буквы()
3. SetNormalizedUserNameAsync не следует ничего делать

Пожалуйста, обратите внимание, что 2.1 может пропустить любой индекс по name столбцу в базе данных и снизить производительность вашего приложения (проверьте свою базу данных еще раз). Или вызвать выполнение «на стороне клиента» (и опять же, резко снизить производительность). В зависимости от вашей реализации.

Я использую такой «свернутый» User класс только во внутренних корпоративных системах, которые используют только определенного поставщика OAuth и принимают пользователей только из указанного домена (Google Apps). Эта система не выполняет никакого поиска по имени пользователя, и я смело использую NotImplementedException множество методов.

1. да, я думал о другом интерфейсе, похожем на IUserLoginStore, с меньшим количеством кода, мне нравится, чтобы эти реализации были более детализированными и не заканчивались не реализованными методами, спасибо за ответ!

2. Некоторые комментарии: 1) В большинстве случаев я бы рекомендовал использовать ToUpperInvariant . 2) Я думаю user.Name , что так и должно быть user.UserName . 3) Во многих случаях я бы также заменил соответствующие варианты нормализации электронной почты (например, FindByEmail ) 4) Если вы используете этот метод, рассмотрите возможность настройки нормализованных столбцов как разреженных столбцов. 5) Кстати, я должен был сделать то же самое до этого . Чистое Ядро. Поведение по умолчанию состояло в нормализации путем встраивания Upper в сгенерированный SQL в обход существующих индексов..

3. Что делать, если вы просто настроили операции получения/поиска для принудительного поиска по электронной почте в любом случае, а методы набора-только для установки электронной почты? Интерфейс должен только реализовывать сигнатуры методов, то, что вы помещаете в них, зависит от вас. Я не проверял это, но задал тот же самый важный вопрос. В любом сценарии реального мира я бы все равно проверил дело по электронной почте и имени пользователя. Насколько существенен прирост производительности, чтобы сделать поля избыточными?

Ответ №3:

Нормализованное имя гарантирует, что символы, используемые в кодировке URL, такие какamp;,? и кавычки, не будут включены, чтобы его можно было использовать в качестве строки запроса() или в URL-адресе, и оно сохранится в кодировке без изменений.

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