Я поразмыслил немного, да и некоторые комментарии навели меня на определенные мысли.
Во-первых у меня было мало времени, т.к. нужно было срочно сделать вменяемую систему авторизации. \Gate:before() в этом контексте было приемлемым и очень элегантным решением — не нужно менять никаких предков, просто поставил и сразу все работает как нужно.
В связи с Policies сразу встал вопрос: как организовать иерархию операций? Тогда мне некогда было об этом думать серьезно.
Сегодня я поразмышлял на эту тему основательно и, в принципе, придумал способ встраивания. Но выглядит это как некоторое притягивание за уши… по крайней мере в нынешнем виденьи.
Конечно использование Policies несколько структурирует пермишины, но с другой стороны и усложняет восприятие целостной картины, а роли еще сильней усложнят ее. Вот и возникает вопрос: а нужно ли это усложнение для не слишком больших проектов? На мой взгляд — нет.
но если вы покажете мне, что где-то при проверке вызывается замыкание или еще что-то в этом роде, то буду вам премного благодарен. А пока я все-таки продолжу настаивать, что Bouncer не может разрешить редактировать только статьи, опубликованные за последний месяц.
В том месте, откуда взята эта цитата, речь шла о больших, серьезных модулях и что в них нет такого простого и нужного механизма (передача параметра в функцию-проверку).
В Laravel такой механизм есть и именно благодаря его наличию существует опираясь на эту инфраструктуру данный модуль.
Но в Laravel нет ролей и это обесценивает Policies на 90%. Фактически они превращаются в фильтры — если я сделаю как написано в примере:
class PostPolicy {
public function update(User $user, Post $post) {
return $user->id === $post->user_id;
}
}
то начну фильтровать всех пользователей. Как же мне тогда "менеджеру" разрешить редактировать все? Писать if? Куда? В код? Спасибо, не надо!
Или в метод update что-то вроде if($user->role=='manager')-elseif-elseif-else? Тоже увольте.
Вот и получается, что Policies есть, а применить их в реальном проекте затруднительно.
Как вы реализуете последовательность проверок в полисях? (update-post → update-post-in-category → update-own-post)
В примере вы определяете пермишин в котором на самом деле проверяете роли… это очень странно, т.е. фактически это эквивалент проверки ролей в коде. В любой статье по RBAC (и в этой тоже) написано, что проверять роли в коде это идеологически неверно. В коде нужно проверять разрешения (операции).
Если в вашем примере administer-users больше не должны видеть какое-то меню, то нужно лезть в код и убирать can('administer-users') бог знает в скольких местах и в каком-нибудь обязательно забыть… В случае вышеописанного модуля необходимо просто в настройках изъять операцию из роли администратора.
Ожидал этого комментария :)
Да, свои могут. А, например, только статьи опубликованные за последний месяц?
Ну то есть, вы же понимаете, что там просто задействованы отношения, а здесь можно воротить что угодно.
Я попробовал Memory Engine мускула - не поддерживает BLOB/TEXT.
Остановился на докер контейнере, создающем базу в ramdisk (tmpfs).
А что вы думаете насчет MySQL MEMORY Storage Engine?
Там правда не поддерживаются TEXT/BLOB...
У приложения Kore тоже есть возможность отправлять текст на медиацентр. Через меню в правом верхнем углу.
Видимо должно быть 120
Я думал вас интересует ABAC как концепция.
Здесь: https://habrahabr.ru/post/321678/#comment_10076076
я уже написал именно по этому поводу.
Я поразмыслил немного, да и некоторые комментарии навели меня на определенные мысли.
Во-первых у меня было мало времени, т.к. нужно было срочно сделать вменяемую систему авторизации. \Gate:before() в этом контексте было приемлемым и очень элегантным решением — не нужно менять никаких предков, просто поставил и сразу все работает как нужно.
В связи с Policies сразу встал вопрос: как организовать иерархию операций? Тогда мне некогда было об этом думать серьезно.
Сегодня я поразмышлял на эту тему основательно и, в принципе, придумал способ встраивания. Но выглядит это как некоторое притягивание за уши… по крайней мере в нынешнем виденьи.
Конечно использование Policies несколько структурирует пермишины, но с другой стороны и усложняет восприятие целостной картины, а роли еще сильней усложнят ее. Вот и возникает вопрос: а нужно ли это усложнение для не слишком больших проектов? На мой взгляд — нет.
Я очень внимательно изучил документацию и даже исходники (но не очень внимательно). И единственное, что я заметил
совершенно не то, о чем мы говорим. Bouncer позволяет разрешить/запретить операцию с какой-то конкретной моделью. Можно глянуть из любопытства сюда:
но если вы покажете мне, что где-то при проверке вызывается замыкание или еще что-то в этом роде, то буду вам премного благодарен. А пока я все-таки продолжу настаивать, что Bouncer не может разрешить редактировать только статьи, опубликованные за последний месяц.
В том месте, откуда взята эта цитата, речь шла о больших, серьезных модулях и что в них нет такого простого и нужного механизма (передача параметра в функцию-проверку).
В Laravel такой механизм есть и именно благодаря его наличию существует опираясь на эту инфраструктуру данный модуль.
Но в Laravel нет ролей и это обесценивает Policies на 90%. Фактически они превращаются в фильтры — если я сделаю как написано в примере:
то начну фильтровать всех пользователей. Как же мне тогда "менеджеру" разрешить редактировать все? Писать if? Куда? В код? Спасибо, не надо!
Или в метод update что-то вроде if($user->role=='manager')-elseif-elseif-else? Тоже увольте.
Вот и получается, что Policies есть, а применить их в реальном проекте затруднительно.
Есть статья "RBAC vs ABAC": https://habrahabr.ru/company/custis/blog/248649/
Не вполне вас понял.
Как вы реализуете последовательность проверок в полисях? (update-post → update-post-in-category → update-own-post)
Если в вашем примере
administer-usersбольше не должны видеть какое-то меню, то нужно лезть в код и убиратьcan('administer-users')бог знает в скольких местах и в каком-нибудь обязательно забыть… В случае вышеописанного модуля необходимо просто в настройках изъять операцию из роли администратора.Я попробую вспомнить и напишу вам.
Да, свои могут. А, например, только статьи опубликованные за последний месяц?
Ну то есть, вы же понимаете, что там просто задействованы отношения, а здесь можно воротить что угодно.