Возможно ли иметь несколько Identity-Instances в одном и том же DBContext?
У нас есть существующее приложение ASP.net Core 2.1, в котором учетные записи пользователей связаны с системой идентификации.
Теперь мы хотели бы добавить пользователей-администраторов, которые не должны совместно использовать таблицу UserAccountsTable, которая уже используется учетными записями пользователей. (Да, я знаю, мы могли бы просто добавить логическую колонку, такую как isAdmin, но мы выбрали отдельные таблицы).
Итак, я подумал, что мне нужно создать новый Identity-Instance, который использует наши классы AdminUser и AdminRole (оба производные от IdentityUser и IdentityRole соответственно).
В DBContext теперь я могу изменить имена таблиц через Fluent-API AdminUser и AdminRole. Но как мне теперь изменить имена необходимых «инфраструктурных» таблиц, созданных Identity автоматически?
Я нашел эта документация от Microsoft. Но они используют только «общие» типы для переименования таблиц, например. Таблица ссылок между пользователями и ролями (IdentityUserRole). Этот тип, вероятно, будет «конфликтовать» с моим уже настроенным UserAccounts-Identity, поэтому «переименовать» обе таблицы, снова создав проблемы, или нет?
Очевидным решением может быть создание нового AdminUserContext, который не будет делиться информацией об учетных записях пользователей. Но тогда мы потеряем ссылки на объекты, которыми действительно хотели бы управлять? И связывание DBContexts не кажется мне «правильным».
У кого-нибудь есть идеи на этот счет?
[дубликат] stackoverflow.com/questions/11197754/…
@ Микев, я должен не согласиться. Моя проблема в другом. Я хочу иметь несколько Identity-Contexts в одном и том же DBContext, а не несколько DBContexts. ;)
@VeNoMiS Я описал выше, что мы специально решили использовать разные таблицы базы данных для этих разных типов входа в систему. Безопасность по замыслу, поэтому никто не может случайно утечь всю базу данных входа для клиентов и администраторов через SQL-инъекцию.
@ghandi вы правы, я предполагаю, что вам нужно реализовать поставщика, который обрабатывает эти случаи. Посмотрите здесь для эталонной реализации.
@ghandi, вы можете просто создавать разные таблицы в OnModelCreating. modelBuilder.Entity<IdentityUser>().ToTable("Users");modelBuilder.Entity<AdminUser>().ToTable("AdminUsers");
@ MSDS561 Это то, о чем я уже говорил выше. Проблема возникает, когда дело доходит до таблицы ссылок для отношения m:n между пользователями и ролями. Эта таблица имеет конкретный тип IdentityUserRole. Но мне нужно различать IdentityUserRole<Users> и IdentityUserRole<AdminUsers>. Поскольку таблица ссылок не может (или не должна) иметь несколько отношений ForeignKey с таблицей пользователей и таблицей пользователей-администраторов, а затем снова с другой стороны отношения к ролям администратора и ролям пользователей. Я решил проблемы с помощью отдельных DBSchema и Migrations. Просто не работает в одном контексте.
в чем проблема использования другого набора разрешений для учетных записей администратора?