Как вам очевидно известно, RBAC — это управление доступом на основе ролей. Все, кто создавали системы чуть большие чем домашняя страничка и чуть меньшие чем Госуслуги, задумывались о том, как разграничить права пользователей. В этой статье я не буду рассказывать о том, что такое RBAC и почему это хорошо (хотя немного, конечно, расскажу), а познакомлю вас со своей скромной разработкой (h-rbac) и попытаюсь объяснить, почему она по некоторым аспектам лучше, чем известные "монстры". EDITED:  Два столпа на которых держится RBAC — это роли и операции (role and permission). Слово "операция" мне нравится больше чем "разрешение", да и смысл отражает более верно. Выглядит это так: Таким образом в коде мы проверяем возможность выполнения операции: В свою очередь модуль RBAC выясняет, разрешена ли для данного пользователя указанная операция (т.е. содержится ли она в его роли) и, если да, то содержимое блока выполняется. Ни в коем случае не стоит проверять в коде наличие у пользователя роли, т.к. сегодня "менеджер" может добавлять в избранное, а завтра уже не может. Искать по тексту и исключать из проверок отдельные роли — дело не благодарное, собственно для этого и существуют "операции". Операция всегда непосредственно связана с блоком программы (см. пример выше) и при изменении ролей здесь точно ничего менять не придется. Зато в состав роли операции включаются и исключаются легко, просто и централизованно. Обычно список ролей и операций хранится в базе данных. Пользователи и роли чаще всего связаны отношением "многие ко многим", таким же отношением связаны и роли с операциями. Все, кто создавали системы чуть большие... что-то я повторяюсь. Короче, все вы знаете основных игроков рынка ограничения доступа для Laravel. Это: Это действительно серьезные продукты имеющие много разных "плюшек" вроде переопределения операций для конкретного пользователя и т.п., но у меня к ним один простой вопрос (прощай карма, нам было хорошо вместе): Как разрешить пользователю редактировать только свои статьи? Хм… а никаких встроенных механизмов для этого нет! И это очень странно, т.к. в большинстве систем пользователи генерируют какой-то контент (например статьи) и должны иметь возможность его редактировать, при этом не имея доступа к редактированию чужого. И еще: что если мой проект не такой уж большой? Что если весь этот геморрой с хранением ролей и операций в БД, связующими таблицами для "многие ко многим" и созданием целого UI для управления всем этим хозяйством излишен?
 — Та-дам! Итак, пришло время поговорить о собственных проделках. Название статьи не случайно звучит "...RBAC для самых маленьких". Речь, конечно, не идет о ТТХ программистов, а скорее о размере проектов (и, конечно же, эта оценка весьма условная). Если в вашем проекте не очень много операций и не очень много ролей и вы не против мечтали хранить их в виде массива, то рад представить вам модуль h-rbac (hierarchical RBAC with callbacks). Сразу хочу признаться, что принцип, использованный в данном модуле, был подсмотрен мной в Yii. Он был избавлен от ненужной (на мой взгляд) сущности Task и реального извращения в виде bizRule, вычисляющейся с помощью eval() (естественно, я говорю о Yii 1.1, в 2.0 стало по-другому, но, на мой взгляд, тоже довольно запутанно). Для работы с модулем требуется Laravel 5.1 или выше. Начать хочется с того, что стандартная система разрешений (операций) появилась в Laravel начиная с версии 5.1. Она имеет хорошую инфраструктуру, много полезных методов, поддерживается в blade и даже позволяет разрешить пользователю редактировать свои статьи (т.е. передавать в проверку аргументы), но(!) там напрочь отсутствуют роли... … все пользователи равны — прямо демократия какая-то. Но мы-то с вами знаем, что обязательно должен быть кто-то "равнее" остальных. Иначе никак! Так вот, модуль h-rbac, по сути, является надстройкой над стандартным механизмом авторизации (не путать с аутентификацией!), добавляющий туда роли, а также иерархию операций. Поэтому вы продолжите пользоваться абсолютно всеми стандартными "плюшками", но в контексте наличия ролей. С помощью Composer Зарегистрируем провайдер в config/app.php Опубликуем нужные нам элементы а именно: EDITED: Начиная с v0.4 модуль поддерживает наличие у пользователя одновременно нескольких ролей. Однако сохранена полная обратная совместимость с предыдущим вариантом, где роль у пользователя была одна и хранилась в поле role модели. Для того, чтобы использовать множественные роли, добавьте в модель User аксессор, который будет возвращать список имен ролей в виде массива (название атрибута можно изменить в настройках модуля): Возьмем следующие роли: и набор операций: Предположим, что мы желаем разделить пользователей на тех, кто может редактировать все статьи, тех, кто будет редактировать статьи только в определенных категориях и тех, кто сможет редактировать только собственные статьи. Для этого мы на самом деле должны создать три операции и объединить их в цепь начиная с самой открытой и до самой ограниченной: Назначение операций ролям очень простое. Кто что может делать очевидно: Обратите внимание, что по существу у нас только две операции update-post и add-to-favorites именно возможность их выполнения мы и должны проверять. Вспомогательные операции update-post-in-category и update-own-post будут проверены автоматически, т.к. они являются содержимым одной с update-post цепи. Операция add-to-favorites подразумевает возможность добавить в избранное любую статью, т.е. никаких дополнительных проверок делать не нужно, достаточно, чтобы эта операция содержалась в роли пользователя. По этой причине можно не передавать в проверку объект $post (но я бы передавал его в любом случае, т.к. сегодня дополнительных условий нет, а завтра могут появиться). Осталось выяснить, как делать проверки тех самых дополнительных условий для update-post-in-category и update-own-post. Для этого достаточно добавить два метода (названия методов получаются путем камелкейсизации(о-па!) названия операции): Параметр $permission в обоих этих методах будет содержать название изначально запрошенной операции update-post. Все операции находящиеся в цепи проверяются одна за другой в выбранном пользователем порядке и операция: Давайте добавим операцию delete-post. Логика подсказывает, что удалять пользователь может те статьи, которые он может редактировать. Подобная ситуация встречается достаточно часто и чтобы не создавать дополнительную цепь операций и абсолютно идентичные функции проверки аргумента воспользуемся одной хитростью — параметром equal: Исходя из этого примера admin сможет удалять любые посты, user — только свои собственные, а вот manager не сможет удалить вообще ничего, т.к. в его роли нет операции delete-post, а значит и проверять ничего не требуется. Как уже было сказано раньше, модуль является надстройкой над стандартной для Laravel 5.1 и выше системой авторизации, поэтому использовать его нужно так, как написано в документации, а если коротенько, то вот вам примерчики: Из модели User: В контроллере: С помощью Blade Кроме того, специально для плохих мальчиков и девочек, добавлена дополнительная директива @role которую можно использовать вместе с @else Вот такой получился модуль, объединяющий мощь стандартных возможностей, действительно необходимый функционал и легкость конфигурации. Спасибо за внимание! P.S.: Чуть не забыл… Названия ролей "admin", "manager" и "user" взяты в этой статье просто в качестве примера. На самом деле роль "admin" встроена в модуль и не требует определения. Она делает пользователя СУПЕРПОЛЬЗОВАТЕЛЕМ. К нему не применяются никакие проверки, ему разрешено абсолютно все. Ура, товарищи! Ссылки: Программирование