Основная идентификация ASP.NET - NormalizedUserName, NormalizedEmail - PullRequest
Новая
       16

Основная идентификация ASP.NET - NormalizedUserName, NormalizedEmail

0 голосов
/ 26 августа 2018

При разработке мультитенантного приложения с ASP.NET Core я заметил, что оно приносит 2 новых индекса: NormalizedUserName & NormalizedEmail.

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

Я имею в виду наличие нескольких пользователей с одинаковым Именем пользователя & Электронной почтой , но разными TenantID .

Чтобы достичь этого, я должен удалить эти индексы 

public static void RemoveIndexes(this ModelBuilder modelBuilder)
{
    modelBuilder.Entity<ApplicationUser>(entity =>
    {
        var normalizedUserNameIndex = entity.HasIndex(u => new { u.NormalizedUserName }).Metadata;
        entity.Metadata.RemoveIndex(normalizedUserNameIndex.Properties);

        var normalizedEmailIndex = entity.HasIndex(u => new { u.NormalizedEmail }).Metadata;
        entity.Metadata.RemoveIndex(normalizedEmailIndex.Properties);
    });
}

Мои вопросы:

  • Какова цель этих двух новых индексов?
  • На что это повлияет, если мы просто удалим их?
  • Есть ли что-то, на что мы должны обратить пристальное внимание после их удаления?(например, переопределение функции по умолчанию UserManager или что-то в этом роде)

1 Ответ

0 голосов
/ 26 августа 2018

Прежде всего, я бы ничего не изменил в Identity Framework, если бы не мог наблюдать за эффектами. Если вы настаиваете, вы можете проверить, что происходит самостоятельно. Но вам нужно удалить поля?

Если отношение пользователь-арендатор равно один-ко-многим , то tenantId не должен быть полем ApplicationUser, а должен храниться в отдельной таблице, например UserClaims .

Вы можете добавить несколько tenantId в качестве заявки одного и того же типа, например http://tenant.company.com/Id.. Затем он станет набором значений, как это происходит с ролями.

Если вы не хотите этого, вы можете использовать различные типы заявок, например http://tenant.company1.com/Id, http://tenant.company2.com/Id или что-то в этом роде.

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

Этот дизайн позволяет пользователю войти в систему, используя один и тот же пароль везде. Обратите внимание, что это касается личности: кто пользователь? Пользователю не нужно иметь разные пароли для каждого арендатора.

Это также упрощает смену пароля. Интересно, как выглядит ваш сценарий с несколькими записями пользователей для каждого арендатора? Будете ли вы обновлять все записи сразу при смене пароля? И как вы будете поддерживать «забытый пароль» и другие функции?

...