Приветствую. Подскажите плиз, верно рассуждаю или нет. Есть различные ресурсы

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

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

Не понял вопроса. Есть например правило: Пользователь может редактировать ресурс, если он создатель, или у него этот ресурс разрешен в вайтлисте или он в группах модератор/администратор. Я это хочу вынести в отдельный модуль.

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

Я все равно не понимаю ) Пользователь и не знает. Мой вопрос вот о чем: Обычно я делал так, есть new resource(data, user_id). Т.е. именно в ресурсе хранилось кто его создал. Но по большей части ресурсу это информация вообще не нужна в его логике. Однако это информация нужна в логике авторизации. Соответсвенно мне кажется что должно быть два класса для ресурса в двух модулях: new AuthResource(resource_id, user_id) и MainResource(data).

что то я уже не понимаю ))

@fes0r начало

тут есть два варианта: - модуль авторизации предоставляет точку расширения которая позволяет зарегистрировать проверку "является ли чел автором ресурса" в модуле ресурсов - поскольку информация "кто создал ресурс" не меняется то можно безопасно добавить это в некий ACL предоставляемый модулем авторизации. В этом случае у тебя вопрос кто слушает ивент "ресурс создан" и кто добавляет запись в ACL. скорее всего ты не хочешь на каждый чих менять модуль авторизации

Я так понимаю, первый вариант это что-то про engine rule

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

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

Куда отнести группы, вайт/блек листы, пермишены которые должны харниться заполняться, если это не отдельный модуль?

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

А так же роли пользователей? Как то всё раскидано выходит

есть такое, но наверное если у тебя role based, то можно и отдельно, даже на шлюзе каком-нить есть ещё вариант подумать над декомпозицией, задаться вопросом "почему правила из других модулей нужны?"

Я больше смотрю к тому, а почему вообще какие то пермишены вообще должны влиять на основной функионал? Например я вообще взял готовый бандл работы с заказами. Я же не смогу на него накрутить пермишены свои, роли и т.д. Только сверху. А какая разница бандл это или мой код?

что ты подразумеваешь под "почему должны влиять на основной функционал"? Просто отрезать проверкой роли? Можно и так, но бизнес любит наворачивать каких-то сложных штук и придётся тягать их из соседних объектов. Но плюс в том, что скорее всего тут не нужно immediate consistency, значит можно спокойно читать без локов. ХЗ почему не можешь накрутить с бандлами, это уже специфика какая-то

Под влиять на основной функицонал имею ввиду следующий кейс: Мы написали некий модуль, без каких либо особенностей авторизации. Он работает, инкапсулирован, есть апи. Прилетает задача с авторизацией, пермишеннами и прочим. И мы начинаем расширять именно текущий модуль, его код. Банально добавляем создателя, хотя для логики этого модуля user_id не нужен, вообще никак, по крайней мере сейчас. Или в его Edit экшен добавляем какие то условия.

Так он ведь нужен. Надо ведь проверить, что текущий юзер равен тому, что записан в создателе

Зачем это именно самому модулю, это не его функционал.

Думаю тут надо отделить вопрос физического разделения и разделения кода по модулям. С точки зрения физ. разделения - важно будет производительность смотреть и если ок, то можно физически по хттп всяким или ещё как куда-то ходить. Т.к. опять же immediate consistency не надо. С точки зрения разделения кода по модулям Тут будет 2 идентификатора - user_id и resource_id, тогда нужно отнести эту связку либо к юзеру, либо к ресурсу. Скорее всего юзер у нас более стабильная штука, поэтому user_id лучше хранить на стороне ресурса