Контроль доступа в symfony, не совсем понимаю тебя?

Question

[Сергей Литвинов]

Добрый день!
Я не совсем понимаю security в symfony 3, доступ к ресурсам там по ролям, и все роли объявляются явно. Но что, если я хочу, скажем, сделать таблицу привилегий в БД и привязывать привилегии к функционалу(добавить пользователя - addUser, удалить задание - delTask, разослать рассылку - sedMultyEmail), а уже сами роли не так важны для приложения, потому что задача системы контроля - обеспечивать доступ по привилегиям, а какая роль имеет какую-то привилегию - это уже другая абстракция, и знать об этом системе не обязательно.
Значит ли это, что в symfony ROLE = привилегия, и у каждого человека их может быть несколько, или я просто не достаточно вдумчиво читал документацию?

Answer 1

[Flying]

Symfony - это в первую очередь framework для обработки HTTP запросов и поэтому многие компоненты по-умолчанию "заточены" именно под этот сценарий.

В конечном итоге вся Symfony Security построена вокруг понятия "токена" (TokenInterface) и большинство частей Security компонента достаточно абстрактны для того чтобы из них можно было собрать весьма разнообразные схемы разделения прав доступа.

Вам необходимо определить для себя что означает "привязка привилегии к функционалу" с точки зрения кода приложения. Вы планируете оставить это разделение прав доступа на уровне "пускать / не пускать по определённому route" или вы будете в сервисах приложения вызывать что-то подобное Security::isAllowed()? Symfony по-умолчанию реализует первый подход, но ничто не мешает вам организовать собственную реализацию основных компонентов. Если вам нужен ACL (а именно так называется "привязка привилегии к функционалу") - то эта функциональность вынесена в отдельный ACL bundle в Symfony 4, скорее всего именно она вам и нужна.

По поводу связки role = privilegy - нет, в общем случае это не так. Необходимо разделять процессы аутентификации (в результате которого подтверждается валидность пользователя и определяются его роли) и авторизации (в результате которого определяется может ли аутентифицированный пользователь получить доступ к тому или иному ресурсу).

Если говорить о работе Symfony Security в контексте обработки HTTP запроса - то аутентификация производится в процессе прохождения запроса через т.н. firewalls, их задача - каким-либо образом определить что это за пользователь и сформировать token. Процесс авторизации построен вокруг т.н. voters которые "голосуют" за/против/воздержался по вопросу "пускать/не пускать", в документации есть целый ряд примеров. Надеюсь факт того что voters могут быть произвольными и иметь любую собственную логику - довольно очевиден. К примеру тот же ACL bundle как раз реализует voter который принимает решение о доступе на основе ACL list'а (который, конечно же, может находиться и в базе данных), но в целом это частный случай.

Comments

[Сергей Литвинов]

Flying, большое спасибо!