Илья, идея есть, хранить роли в бд приложения. Но не понятно многие моменты. Например нужно ли также дополнительно в приложении хранить и пользователей. Как проверять эти локальные роли во фронте (в виде какого то отдельной службы может быть).
Если есть возможность, можно было бы и созвониться ))
Илья, Да, у каждого приложения свои роли и разрешения и свой администратор который изменяет эти роли. Как я понял эти роли должны храниться в именно в приложении а не в IS. Как, например, описывают в этой статье: href="https://leastprivilege.com/2016/12/16/identity-vs-..."
Илья, Есть проект или приложение Identity Server с поставщиком asp.net Identity, где будут все пользователи и роли, допустим. Есть другие проекты который используют этот Identity Server для входа. Для каждого пользователя есть разные роли для разных приложений. Получается все эти роли вместе с пользователями будут в проекте Identity Server с поставщиком asp.net Identity? И при изменении администратор одного из приложения, должен лезть в Identity Server чтобы изменить роль?
Илья, Да, стоит интеграция. Я планирую в Identity Server хранить пользователей с общей информацией (отдел, должность и т. д.). Читал на форумах, что не правильно хранить специфичную информацию в Identity Server (роли и т. д.).
Спасибо! Правильно ли хранить роли в Identity Server? Один пользователь в одном приложении может быть Admin а в другом User. И управление ролями тоже перенесется в IS.
Максим, Спасибо большое Максим! Наверное, в моем случае, по крайней мере пока, Group, будет Value Object, где будет хранится только id, т.е. не Group а GroupId. В логике, в условиях я опираюсь только на Id. А значение я буду получать из хранилища для отображения, одним из способов, которые вы описали. И хотелось бы уточнить )). Когда вы спрашивали, нужны ли эти группы в приложении, вы имели ввиду: веду ли я работу отдельно с ними (добавление, удаление, редактирование, т. е запуск отдельного бизнес процесса), или же они нужны только для описания сущности и возможно в зависимости от их значения, они могут повлиять на бизнес процесс в этой сущности?
Максим, Создавать DTO в Application не нужно? Передаем доменную сущность в контроллер, а там подтягиваем данные? Тогда надо получить доступ к хранилищу через репозиторий. А это хорошо, делать запросы к БД с API слоя ? Насколько я понимаю, в котроллер нужно передать все нужные данные или я ошибаюсь? Спасибо)
Максим, Т. е. в слое Application, например в UseCase, нужно будет преобразовать доменную сущность в DTO (где будут подгружены значения по id из справочников), а потом отправить в контроллер? В контроллере (слой Api) вызываю UseCase и, либо сразу передаю на фронт DTO, либо преобразую во ViewModel, которая хранится в этом же слое?
Спасибо Максим! В приложении используется именно Id, например в условии, отображать заявку только пользователям с таким же GroupId. Но для отображения, в списке заявок или деталях, мне нужно название. Поэтому в агрегатах я храню ссылку на Group. А если вынести Group в агрегат, то насколько я знаю, хранить в других агрегатах мы можем только GroupId.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Если есть возможность, можно было бы и созвониться ))