Yii Framework

Как вы совмещаете автризацию и DDD подход?
Например, обычный юзер может менять свою анкету, но не может поменять e-mail.
Но админ может в том числе и e-mail поменять.
Получается, нужно вплетать авторизацию в слой домена, и получается нужно писать свое решение, а не использовать yii RBAC.

Или тут лучше всего в апп слое определить интерфейс (например, UserService), а в инфраструктуре его реализовать используя yii RBAC?

И вообще, доменный слой должен знать об авторизации? Или авторизация реализуется в других слоях?

Аутентификация делается на уровне App.

Авторизация размазана по слоям - частично в App, а частично в домене, потому что авторизация обычно отчасти составляет бизнес-логику. Например, "юзер может удалять только свой коммент, если не прошло более 5 минут с момента постинга и нет последующих ответов с его цитированием".

Ну и RBAC в DDD вряд ли применим, потому что авторизационные вещи будут по домену размазаны. Как туда RBAC вкрутить с его ролями и пермишенами? RBAC очень примитивная штука. Если он применим, то DDD на проекте излишен. Имхо.

https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.

rugabarbo писал(а): ↑2018.01.06, 03:27 "юзер может удалять только свой коммент, если не прошло более 5 минут с момента постинга и нет последующих ответов с его цитированием".

Это непосредственно БЛ.
Я спрашивал немного о другом.

Я думаю, как ограничить юзеров от изменений части каких-то данных.
Например, если юзер менят данные профиля вместе с эл.почтой, то UserService::updateProfile для админа выполнится, а для простого юзера выкинет исключение.

Ну да, похоже, подобной авторизации место в апп сервисах.

rugabarbo писал(а): ↑2018.01.06, 03:49 https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.

Читал пару раз, хорошая статья. Но толком ABAC не понял, хоть и получил базовое представление.
RBAC по сравнению с ABAC слишком прост. Но мне пока и RBAC хватает.

Bio man писал(а): ↑2018.01.06, 05:10

rugabarbo писал(а): ↑2018.01.06, 03:27 "юзер может удалять только свой коммент, если не прошло более 5 минут с момента постинга и нет последующих ответов с его цитированием".

Это непосредственно БЛ.

Это авторизация, являющаяся частью бизнес-логики.

Bio man писал(а): ↑2018.01.06, 05:10 Ну да, похоже, подобной авторизации место в апп сервисах.

Если авторизацию можно сделать в апп без погружения в домен, то так и следует сделать.

Bio man писал(а): ↑2018.01.06, 05:11

rugabarbo писал(а): ↑2018.01.06, 03:49 https://habrahabr.ru/company/custis/blog/248649/ - советую почитать, чтобы осознать примитивность RBAC. Доступно изложено.

Читал пару раз, хорошая статья. Но толком ABAC не понял, хоть и получил базовое представление.

Мой пример авторизации на право удалить коммент - это и есть функционал, требующий ABAC. Здесь RBAC не поможет, потому что ролями и пермишенами эта авторизация не разруливается.

rugabarbo писал(а): ↑2018.01.06, 10:51Мой пример авторизации на право удалить коммент - это и есть функционал, требующий ABAC. Здесь RBAC не поможет, потому что ролями и пермишенами эта авторизация не разруливается.

но йиишная реализация rbac поддерживает правила любой сложности.

zelenin писал(а): ↑2018.01.07, 16:04

rugabarbo писал(а): ↑2018.01.06, 10:51Мой пример авторизации на право удалить коммент - это и есть функционал, требующий ABAC. Здесь RBAC не поможет, потому что ролями и пермишенами эта авторизация не разруливается.

но йиишная реализация rbac поддерживает правила любой сложности.

Да, тут я слегка обманул автора, чтобы он не понавтыкал в своём DDD повсеместно user->can() вызовов, вытаскивая бизнес-логику с уровня домена в апп-слой.

Аутентификация делается на уровне App.

Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.

noLogicOnlyWar писал(а): ↑2018.01.08, 14:31

Аутентификация делается на уровне App.

Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.

Классический пример: в консоли аутентификация не требуется, в REST API делается по токену, на сайте - по паролю. Всё это апп-слой. Реализация в каждом разная. Домен у всех один.

rugabarbo писал(а): ↑2018.01.08, 14:36

noLogicOnlyWar писал(а): ↑2018.01.08, 14:31

Аутентификация делается на уровне App.

Вот интересно, откуда пошло такое мнение? Во всех учебных примерах, которые я видел, так или иначе аутентификация в домене.

Классический пример: в консоли аутентификация не требуется, в REST API делается по токену, на сайте - по паролю. Всё это апп-слой.

вообще так или иначе все в app-слое. Это не значит, что все относится к нему.

rugabarbo писал(а): ↑2018.01.08, 14:36Реализация в каждом разная. Домен у всех один.

да, в домене один интерфейс - реализации разные. Классическая ситуация.

Вероятно, мы говорим о разных подходах: https://medium.com/@martinezdelariva/au ... 1f7a5596ac

вполне может быть. однозначно сказать, что авторизация - это такой-то слой нельзя. Это зависит от условий, описания домена, желания, звезд на небе итд.
Например при разработке api для третьих лиц я однозначно бы делал авторизацию частью доменного слоя.
В случае с crud-админкой я бы прикрывал экшны сервисом авторизации презентационного слоя, а разруливал доступ к данным сервисом слоя приложения.
Итд.

Согласен. Моя ошибка. Аутентификация не делается, а может делаться на уровне апп до погружения в домен.

И я всё-таки больше про аутентификацию. Про авторизацию вообще тема сложная вплоть до реализации отдельных полиси-служб и т.д.

zelenin писал(а): ↑2018.01.08, 15:54 В случае с crud-админкой я бы прикрывал экшны сервисом авторизации презентационного слоя, а разруливал доступ к данным сервисом слоя приложения.

Сервис авторизации презентационного слоя это yiiшный authManager?
Я правильно понял, что ты предлагаешь авторизацию разруливать в контроллерах через authManager? Или как?

И еще вопрос. Это нормальная практика, когда из слоя представления обращаются к домену (к сущностям, VO) напрямую?

Bio man писал(а): ↑2018.01.11, 16:45 И еще вопрос. Это нормальная практика, когда из слоя представления обращаются к домену (к сущностям, VO) напрямую?

Безусловно нормальная. Домен более устойчив в плане возможных изменений, чем презентация. Делать декоуплинг в презентации от домена - ничем неоправданая работа.