Как удалить связанные с ролями таблицы из ASP.NET Identity Core 2.0

С советом, прочитанным в другом месте, что роли являются подмножеством утверждений, я ищу чистый способ попросить реализацию EF Core в ASP.NET Identity не создавать связанные с ролями таблицы в шаблоне ASP.NET Identity Core 2.0 в VS. 2017. Нужны только претензии. В шаблоне используется

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
{
    public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
        : base(options)
    {
    }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);
        // Customize the ASP.NET Identity model and override the defaults if needed.
        // For example, you can rename the ASP.NET Identity table names and more.
        // Add your customizations after calling base.OnModelCreating(builder);
    }
}

И IdentityDbContext создает эти таблицы, связанные с ролями.

https://github.com/aspnet/Identity/blob/dev/src/Microsoft.AspNetCore.Identity.EntityFrameworkCore/IdentityDbContext.cs

Как избавиться от них, не манипулируя файлами миграции?


asp.net-core-2.0 asp.net-identity ef-core-2.0
person Octopus    schedule 24.10.2017    source источник

Ответы (2)


arrow_upward
7
arrow_downward

Это всегда было возможно в ASP.NET Identity, но со временем стало проще, поскольку соглашения отошли от ролей к правам, действиям, утверждениям, предикатам и другим более многоразовым и поддерживаемым семантикам. Я много лет использую Identity в своих проектах ASP.NET с уже существующими схемами БД (в которых нет таблиц ролей). Признаюсь, довольно сложно понять, как это сделать из-за громоздкой сложности ASP.NET Identity, а также быстро меняющихся изменений открытого исходного кода, происходящих в ASP.NET, в сочетании с полным отсутствием человеко-информированной документации. в справке по API (которая полностью сгенерирована машиной).

До ASP.NET Core это можно было сделать, переопределив реализации UserManager и UserStore. Заглушая запросы ролей без операций или заменяя реализацию RoleAttribute более полезной и безопасной для разработчиков (вероятно, не основанной на магических строках!), отсутствие таблиц ролей остается незамеченным. Даже при использовании реализаций по умолчанию, если вы никогда не использовали реализации атрибутов ролей по умолчанию или не задавали вопросы о ролях, таблицы можно было бы удалить без каких-либо последствий. Ни один из шаблонов ASP.NET по умолчанию не зависит от ролей.

В исходных версиях ASP.NET Core Identity 1.0/1.1 это делалось путем реализации UserStore без дополнительного интерфейса IUserRoleStore. Информацию об этом можно найти в разделе основная документация по удостоверению ASP.NET Core.

Что касается ASP.NET Core 2.0 (по вашему основному вопросу), вы можете сделать это проще, получив свой контекст от IdentityUserContext вместо IdentityDbContext, как показано в примере ниже. Это больше не требовало пользовательских реализаций в версии 2.0 из-за новый UserOnlyStore. Вызов AddIdentity в Startup.cs также необходимо заменить на AddIdentityCore. AddIdentityCore требует несколько дополнительных строк кода, если вы зависите от других стандартных функций аутентификации, поскольку по умолчанию он не инициализирует файлы cookie или TokenProviders. (Как отмечено ниже, в версии 2.1 изменения шаблона Startup больше не требуются.)

Удалить роли в ASP.NET Core 2.1/2.2 (на момент написания этой статьи) довольно просто. Вот пример использования нового проекта для демонстрации:

  1. Создайте новый проект для демонстрации личности, выбрав:

    1. ASP.NET Core Web Application project type
    2. Веб-приложение (любой тип, например MVC)
    3. Изменить аутентификацию
    4. Индивидуальные учетные записи пользователей
    5. Храните учетные записи пользователей в приложении

  2. Удалите роли из недавно созданного проекта Identity.

    1. edit Data\ApplicationDbContext.cs, elevating the context base class above roles
      • from: ApplicationDbContext : IdentityDbContext
      • to: ApplicationDbContext : IdentityUserContext<IdentityUser>
    2. обратите внимание, что IdentityUserContext требует универсального IdentityUser
    3. из-за нового идентификационного кода в ASP.NET Core 2.1 это все, что требуется

  3. Обратите внимание, что в IdentityUserContext отсутствует роль, поэтому для настраиваемых типов ключей требуется только 2 аргумента.

    1. in ApplicationDbContext.cs: IdentityUserContext<IdentityUser<int>, int>
    2. в Startup.cs по-прежнему указано AddDefaultIdentity<IdentityUser<int>>()
    3. Модель, предоставляемая _LoginPartial.cshtml, также указывается, как и раньше. подробнее об изменении моделей идентификации
    4. if you've changed identity key type, the default EF Migration process fails
      1. EF generates non-functional migrations if you've changed keys
      2. simply deleting Data\Migrations works in test, with these caveats:
        • the scaffolded project included indices that are not default
        • если вы уже запустили проект, вам нужно удалить БД

  4. Обновите/создайте схему базы данных, чтобы отразить вышеизложенное. В консоли диспетчера пакетов:

    1. Add-Migration RemoveIdentitySchemaRoles
    2. Update-Database

  5. Запустите приложение

person shannon    schedule 12.01.2019
comment
Это лучший ответ, к которому я пришел. К сожалению, AddDefaultIdentity использует интерфейс по умолчанию, который является загрязнением. Но я не могу придумать лучшего решения, кроме создания нового AddIdentity. - person Octopus; 12.02.2019

arrow_upward
1
arrow_downward

Вы не можете, и весьма вероятно, что Личность перестала бы функционировать, если бы вы это сделали. Нравится вам это или нет, Identity использует роли. Вы можете отказаться от этой функции, но тем не менее она есть.

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

person Chris Pratt    schedule 24.10.2017
comment
Не могли бы вы рассказать больше о том, почему утверждения являются абстрактными понятиями? Я все еще могу фильтровать претензии, которые можно рассматривать как нечто конкретное. (?) docs.microsoft.com/en-us/aspnet /ядро/безопасность/авторизация/ - person Octopus; 24.10.2017
comment
Они абстрактны, потому что не имеют неявной функциональности. Это просто данные. Вы должны создать функциональность вокруг этих данных. Например, вы можете добавить утверждение, указывающее, что пользователь является администратором, но тогда вам потребуется некоторая логика, чтобы извлечь это утверждение, проверить значение и принять решение о статусе пользователя. Роли — это просто утверждения с этой встроенной функциональностью. - person Chris Pratt; 24.10.2017
comment
Есть ли у вас соответствующие документы, в которых подробно обсуждаются различия между утверждениями и ролями? Кажется, не хватает в предоставленной ссылке. Спасибо - person Octopus; 24.10.2017
comment
В связи с этим, я хочу установить базу данных покупателей/продавцов, если я вас хорошо понимаю, роли будут здесь. - person Octopus; 24.10.2017
comment
У меня нет документации, чтобы указать вам, но это просто основы информатики. Заявки — это токены данных. В реализации Identity это буквально словарь или пары ключ-значение. Роли буквально представляют собой утверждения с прикрепленным поведением, т. е. значение утверждения определяет уровни авторизации. - person Chris Pratt; 24.10.2017
comment
Роли могут быть одним из способов справиться с этим. Строго говоря, роли должны быть ориентированы на действия. Например, вместо роли покупателя у пользователя должна быть что-то вроде роли can_buy. В этом сценарии это не очень значимое различие, но когда дело доходит до таких вещей, как наличие роли администратора, это немного завышено в отношении того, какие роли должны быть. - person Chris Pratt; 24.10.2017
comment
На самом деле роли, вероятно, не основаны на действиях в большинстве семантик; то, что вы имеете в виду, вероятно, будет считаться правами. Это был один из распространенных аргументов в пользу отказа от реализации роли удостоверения ASP.NET, которая изначально не поддерживала несколько ролей, и даже сегодня довольно громоздко рассматривать ее как права. - person shannon; 07.01.2019
comment
Всегда можно было удалить роль из реализации Identity, внедрив собственный UserManager. В последнее время рассмотрение этого было построено более изящно. github.com/aspnet/Identity/issues/1269 - person shannon; 07.01.2019