авторизация и DDD
авторизация и DDD
Как вы совмещаете автризацию и DDD подход?
Например, обычный юзер может менять свою анкету, но не может поменять e-mail.
Но админ может в том числе и e-mail поменять.
Получается, нужно вплетать авторизацию в слой домена, и получается нужно писать свое решение, а не использовать yii RBAC.
Или тут лучше всего в апп слое определить интерфейс (например, UserService), а в инфраструктуре его реализовать используя yii RBAC?
И вообще, доменный слой должен знать об авторизации? Или авторизация реализуется в других слоях?
Например, обычный юзер может менять свою анкету, но не может поменять e-mail.
Но админ может в том числе и e-mail поменять.
Получается, нужно вплетать авторизацию в слой домена, и получается нужно писать свое решение, а не использовать yii RBAC.
Или тут лучше всего в апп слое определить интерфейс (например, UserService), а в инфраструктуре его реализовать используя yii RBAC?
И вообще, доменный слой должен знать об авторизации? Или авторизация реализуется в других слоях?
Re: авторизация и DDD
Аутентификация делается на уровне App.
Авторизация размазана по слоям - частично в App, а частично в домене, потому что авторизация обычно отчасти составляет бизнес-логику. Например, "юзер может удалять только свой коммент, если не прошло более 5 минут с момента постинга и нет последующих ответов с его цитированием".
Ну и RBAC в DDD вряд ли применим, потому что авторизационные вещи будут по домену размазаны. Как туда RBAC вкрутить с его ролями и пермишенами? RBAC очень примитивная штука. Если он применим, то DDD на проекте излишен. Имхо.
Авторизация размазана по слоям - частично в App, а частично в домене, потому что авторизация обычно отчасти составляет бизнес-логику. Например, "юзер может удалять только свой коммент, если не прошло более 5 минут с момента постинга и нет последующих ответов с его цитированием".
Ну и RBAC в DDD вряд ли применим, потому что авторизационные вещи будут по домену размазаны. Как туда RBAC вкрутить с его ролями и пермишенами? RBAC очень примитивная штука. Если он применим, то DDD на проекте излишен. Имхо.
Последний раз редактировалось rugabarbo 2018.01.06, 03:50, всего редактировалось 1 раз.
Re: авторизация и DDD
https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.
Re: авторизация и DDD
Это непосредственно БЛ.
Я спрашивал немного о другом.
Я думаю, как ограничить юзеров от изменений части каких-то данных.
Например, если юзер менят данные профиля вместе с эл.почтой, то UserService::updateProfile для админа выполнится, а для простого юзера выкинет исключение.
Ну да, похоже, подобной авторизации место в апп сервисах.
Re: авторизация и DDD
Читал пару раз, хорошая статья. Но толком ABAC не понял, хоть и получил базовое представление.rugabarbo писал(а): ↑2018.01.06, 03:49 https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.
RBAC по сравнению с ABAC слишком прост. Но мне пока и RBAC хватает.
Re: авторизация и DDD
Это авторизация, являющаяся частью бизнес-логики.
Если авторизацию можно сделать в апп без погружения в домен, то так и следует сделать.
Мой пример авторизации на право удалить коммент - это и есть функционал, требующий ABAC. Здесь RBAC не поможет, потому что ролями и пермишенами эта авторизация не разруливается.Bio man писал(а): ↑2018.01.06, 05:11Читал пару раз, хорошая статья. Но толком ABAC не понял, хоть и получил базовое представление.rugabarbo писал(а): ↑2018.01.06, 03:49 https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.
Re: авторизация и DDD
-
- Сообщения: 83
- Зарегистрирован: 2017.07.04, 20:53
Re: авторизация и DDD
Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.Аутентификация делается на уровне App.
Re: авторизация и DDD
Классический пример: в консоли аутентификация не требуется, в REST API делается по токену, на сайте - по паролю. Всё это апп-слой. Реализация в каждом разная. Домен у всех один.noLogicOnlyWar писал(а): ↑2018.01.08, 14:31Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.Аутентификация делается на уровне App.
Re: авторизация и DDD
вообще так или иначе все в app-слое. Это не значит, что все относится к нему.rugabarbo писал(а): ↑2018.01.08, 14:36Классический пример: в консоли аутентификация не требуется, в REST API делается по токену, на сайте - по паролю. Всё это апп-слой.noLogicOnlyWar писал(а): ↑2018.01.08, 14:31Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.Аутентификация делается на уровне App.
да, в домене один интерфейс - реализации разные. Классическая ситуация.
Re: авторизация и DDD
Вероятно, мы говорим о разных подходах: https://medium.com/@martinezdelariva/au ... 1f7a5596ac
Re: авторизация и DDD
вполне может быть. однозначно сказать, что авторизация - это такой-то слой нельзя. Это зависит от условий, описания домена, желания, звезд на небе итд.
Например при разработке api для третьих лиц я однозначно бы делал авторизацию частью доменного слоя.
В случае с crud-админкой я бы прикрывал экшны сервисом авторизации презентационного слоя, а разруливал доступ к данным сервисом слоя приложения.
Итд.
Например при разработке api для третьих лиц я однозначно бы делал авторизацию частью доменного слоя.
В случае с crud-админкой я бы прикрывал экшны сервисом авторизации презентационного слоя, а разруливал доступ к данным сервисом слоя приложения.
Итд.
Re: авторизация и DDD
Согласен. Моя ошибка. Аутентификация не делается, а может делаться на уровне апп до погружения в домен.
Re: авторизация и DDD
И я всё-таки больше про аутентификацию. Про авторизацию вообще тема сложная вплоть до реализации отдельных полиси-служб и т.д.
Re: авторизация и DDD
Сервис авторизации презентационного слоя это yiiшный authManager?
Я правильно понял, что ты предлагаешь авторизацию разруливать в контроллерах через authManager? Или как?
Re: авторизация и DDD
И еще вопрос. Это нормальная практика, когда из слоя представления обращаются к домену (к сущностям, VO) напрямую?
Re: авторизация и DDD
Безусловно нормальная. Домен более устойчив в плане возможных изменений, чем презентация. Делать декоуплинг в презентации от домена - ничем неоправданая работа.