воутер на одну, воутер на другую...

как вариант какой-то общий брать и искать клиентский ид вверх

а что если делать по воутеру на роль?

по воутеру на роль + контекст?

контекст в разрезе домена?

как вариант какой-то общий брать и искать клиентский ид вверх

если тебе позволяет твое приложение обобщать правила - окей

не позволяет, ты прав

мое например не особо позволяет)

то так было, идея в воздух

теоретически можно писать один общий + много меньших

т.к.

- тормозной, у меня сотни миллионы обьектов (хотя их подход интересный в плане оптимизации нагрузок) - разграничивать права по пользователям - гуд, но мне нужно развести права еще на группы. В принципе, любой объект может быть владельцем других объектов

у меня часть воутеров имеет свитч-кейс по действиям на них, а часть просто проверяет принадлежность и кидает 403 при ошибке

и, возможно, проверку на 403 имеет смысл вынести "наверх"

- тормозной, у меня сотни миллионы обьектов (хотя их подход интересный в плане оптимизации нагрузок) - разграничивать права по пользователям - гуд, но мне нужно развести права еще на группы. В принципе, любой объект может быть владельцем других объектов

- сотни и миллионы объектов которые ты грузишь в воутеры? что? - в чем проблема с группами? у меня есть 5 ролей пользователей, которые имеют доступ к определенным ресурсам (причем с пересечением и для каждоой роли свои проверки).

у меня часть воутеров имеет свитч-кейс по действиям на них, а часть просто проверяет принадлежность и кидает 403 при ошибке

кидает 403 или говорит просто что "низя"?

403, т.к. проверяю по is_granted аннотации (ну или дергаю напрямую в коде, я еще не решил, как лучше) ну и дальше уже хендлер обрабатывает исключение и отдает страничку с мессенджем

а ну это ж не сам воутер, это уже AuthorizationChecker делает

дергается воутером оно)

тьфу

чекер дергает воутер

нет. Не гружу сотни лямов объектов в вотеры. Наверно не совсем корректно выразился. У меня есть - классические пользователи - классические группы - классические роли В целом, все хорошо. Но как обычно, всегда есть но. Я должен навешивать разрешения не только на пользователя/группу/роль, но и на любой произвольный объект, коих очень много и они все разные

нет. Не гружу сотни лямов объектов в вотеры. Наверно не совсем корректно выразился. У меня есть - классические пользователи - классические группы - классические роли В целом, все хорошо. Но как обычно, всегда есть но. Я должен навешивать разрешения не только на пользователя/группу/роль, но и на любой произвольный объект, коих очень много и они все разные

я бы в этом случае сделал бы отдельно привязку

и тогда все довольтно просто и тривиально

к примеру как?

что-то типа хранить спецификации доступа для сущностей. Ну и как правило у тебя будут дефолтные которые можно расширять (вайт лист пользователей какой-нибудь)

ну то есть вот вообще отдельно все это. ОТдельные таблички, никаких FK, тип сущности, айдишка, кому и чего можно

хм, заманчиво. Есть примеры решений?

хз но делается за вечер

если без UI

он особо и не нужен, этот UI )

а как ты будешь "гибко настраивать что кому можно?"

эх )))

или речь не идет о том что бы можно было для каждой отдельной штуки асайнить права доступа

?

я не буду настраивать. Права бдут подтягиваться из 1C, редмайна, лдап и раздаваться автоматом)))

или речь не идет о том что бы можно было для каждой отдельной штуки асайнить права доступа

идет

я не буду настраивать. Права бдут подтягиваться из 1C, редмайна, лдап и раздаваться автоматом)))

а ну так норм

не совсем. Мозг ломает сильно тк никто и никогда не думал о разграничении доступов в этих подсистемах и все они живут своей отдельной жизнью )

вот по этому воутеры это офигенно.... ты можешь просто по началу всем все разрешать но делать проверки)

а потом все так вот вжух и разрулил)

но конечно для этого надо уже понимать что "проверки прав доступа делать надо всегда". Конечно если ты не личный блог пишешь

так и было. Но потом количество вотеров, исключений и правилл накопилось столько, что просто мракобесие. Хочется все причесать и упорядочить

так и было. Но потом количество вотеров, исключений и правилл накопилось столько, что просто мракобесие. Хочется все причесать и упорядочить

для этого надо погружаться в проект, что явно выльется в этом чатике в нарушение NDA какое)

воутеры - это просто механизм позволяющий тебе организовать какие хочешь проверки. Если тебе не удобно с воутерами, то попробуй перегруппировать проверки

но конечно для этого надо уже понимать что "проверки прав доступа делать надо всегда". Конечно если ты не личный блог пишешь

нет, не блог. Для понимания количества обектов, могу привести ебей. Тьма товаров, все они разные, тьма пользователей..... мрак Да, NDA есть, куда же без него) Поэтому и не могу конкретнее описать масштаб проблем)

если все еще не удобно - придумываем новые типы проверок (как случай когда нам надо отдельно хранить кто куда ходить может)

нет, не блог. Для понимания количества обектов, могу привести ебей. Тьма товаров, все они разные, тьма пользователей..... мрак Да, NDA есть, куда же без него) Поэтому и не могу конкретнее описать масштаб проблем)

тьма товаров - да, но действия над товарами может производить не тьма людей.

подумай еще над моей идеей разделить проверки на воутерах по уровням

ну то есть формализовать правила не особо сложно если посидеть, порисовать и подумать

подумай еще над моей идеей разделить проверки на воутерах по уровням

ну вот я сколько не пробовал - идея делать по воутеру на сущность приводит к раку.

то бишь, если у тебя есть возможность группировать их (как говорит Сергей) - возможно, получится разложить их "по полочкам" и сделать "конвеер"

люди могут входить в группы, группы могут быть вложенными, люди в группах пересекаются... А еще у людей есть есть индивидуальные роли...

люди могут входить в группы, группы могут быть вложенными, люди в группах пересекаются... А еще у людей есть есть индивидуальные роли...

это вопрос модели данных которую ты выбрал, ничего сложного

ну вот я сколько не пробовал - идея делать по воутеру на сущность приводит к раку.

у меня по воутеру на сущность сейчас потому, что походу каждая сущность - уже контекст

ну то есть... ясно что "сложна", но это к воутерам никакого отношения не имеет.

то, о чем мы говорили - я не могу выделить контекст "биллинг" или "инвентарь" как в примерах всяких

и это усложняется еще и иерархичностью сущностей

и это усложняется еще и иерархичностью сущностей

ничего не усложняется, грамотно определи границы агрегатов

там где у тебя "вложенные сущности" часто не сущности а только их айдишки на самом деле

границы функций, ими выполняемых?

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

вот пример. есть обект А есть лярд, обектов Б, С, Д.... Нужно получить список обектов, которые может редактировать обьекта А. Вотеры тут не особо помогут (

окей, гугл как определить, где у меня сущности, а где их айдишки?) идея с shared айдишками?

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

вкуривал, да не вкурил еще

ERROR: S client not available

вот пример. есть обект А есть лярд, обектов Б, С, Д.... Нужно получить список обектов, которые может редактировать обьекта А. Вотеры тут не особо помогут (

а зачем тебе получать этот список в проверке авторизации действий?

плаваю

окей, гугл как определить, где у меня сущности, а где их айдишки?) идея с shared айдишками?

если все что тебя интересует - референс на сущность - тебе хватит только айдишки)

и это сильно развязывает руки в плане того что и как можно разделить

К примеру удалили обект А. Нужно удалить все разрешения - это просто пример

К примеру удалили обект А. Нужно удалить все разрешения - это просто пример

ммм.... причем тут ACL? ты можешь потом просто почистить мусор. Еще есть доменные ивенты и прочие штуки.

или просто просмотреть в UI куда имеет доступ обект А

если все что тебя интересует - референс на сущность - тебе хватит только айдишки)

а что еще может интересовать?)

или просто просмотреть в UI куда имеет доступ обект А

ну это ж сам понимаешь к ACL никакого отношения уже не имеет

а что еще может интересовать?)

ну тип там методы в рамках бизнес транзакции надо дергать

нет, не имеет, но очень рядом)

а еще - часто то что ты думаешь должно происходить в рамках одной бизнес транзакции на самом деле две разных

и очень много "проблем" в том что бы видеть границы вызывают привычки и UI

последнее чаще всего приводит к добавлению непонятных связей в сущностях которые даже не нужны

и очень много "проблем" в том что бы видеть границы вызывают привычки и UI

+

ну тип там методы в рамках бизнес транзакции надо дергать

во, в моем случае зачастую нужно дергать методы или создавать новые агрегируемые сущности

во, в моем случае зачастую нужно дергать методы или создавать новые агрегируемые сущности

а ты в этом уверен?)

последнее чаще всего приводит к добавлению непонятных связей в сущностях которые даже не нужны

со связями у меня тоже печально.... впрочем, это все нужно рассматривать на конкретных примерах конкретных действий

нужно посмотреть и еще раз подумать

блин я плохо помню что там у тебя за штуки

+ у тебя там тоже NDA....

я не особо описывал детали того, что где происходит

да я думаю себе выписать на листок куда-то схему действий, которые можно выполнять в системе

и желательно со связями, какие действия что затрагивают

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

вот пример. есть обект А есть лярд, обектов Б, С, Д.... Нужно получить список обектов, которые может редактировать обьекта А. Вотеры тут не особо помогут (

а это точно авторизация доступа? Обычно задача авторизации заключается в простом "имеет ли объект А доступ к объекту Б)

а это точно авторизация доступа? Обычно задача авторизации заключается в простом "имеет ли объект А доступ к объекту Б)

это скорее управление правами

ну то есть обычная логика приложения, фреймворк тут мало чем поможет

а это точно авторизация доступа? Обычно задача авторизации заключается в простом "имеет ли объект А доступ к объекту Б)

Нет, это уже не авторизация, а как заметил Сергей - управление правами

да как бы дело и не во фреймворке. Изначально то я хотел найти и посмотреть альтернативы симфонийскому ACL ) У всех своя специфика, если конечно речь не о личном блоге)

Спасибо, коллеги. Натолкнули меня на пару интересных идей. Пойду думать)