Спасибо за статью. Еще можно было бы использовать RBAC + бизнес правила. Мне кажется, хорошо подходит для вашей задачи. В yii2 работает из коробки. С symphony я не работал, к сожалению, но навеняка есть бандл для работы с rbac
В symfony RBAC тоже работает из коробки, и раньше он меня всегда устраивал. Но в этом проекте администратор должен иметь возможность отредактировать любые привилегии каждой роли, а это, на минуточку, 13*7 + 8 глобальных привилегий. Код уже начинает попахивать… Плюс то, что у пользователя может быть несколько из ~20 «настоящих» что-то значащих ролей, и у каждой из них есть ворох ролей, описывающих их привилегии. А если бы заказчик захотел бы добавить/удалить некоторые из них (пусть тот, у кого такого не было первый кинет в меня камень)? Я же застрелился бы!
Года 3 назад у меня был проектик со схожей ситуацией, писался на Yii с его RBAC. Там было где-то 7 ролей, но сложные правила вроде «пользователь может паблишить айтем только если его заапрувило минимум два чувака с такой-то ролью или один чувак с другой ролью». Ну и таких правил было не мало. На Yii вышло ужасно. А догадаться сделать цепочку обязанностей (что собственно воутеры из себя и представляют) на тот момент я не догадался.
Всё же следует различать, где безопасность (информационная), а где бизнес-логика. Правило, которое вы описали, выглядит как ограничение бизнес-процессов, а не как правило безопасности.
Ну как бы да, с другой стороны это ограничение бизнес логики налагается на действия которое могут производить пользователи, и если RBAC дает весьма примитивные возможности то воутеры как раз таки хорошо подходят для таких случаев.
Symfony2 Voters и Doctrine Filters на страже безопасности