Symfony, SPA аутентификация, какова лучшая практика в настоящий момент?

Question

[Матвей Румынин]

Требуется подсказка от опытных в symfony товарищей
Задался вот таким вопросом. Если проект на symfony является REST-сервисом и полностью отделен от веб-приложения, есть ли какой-то смысл строить аутентификацию так, как предлагается в security? Предполагается 3 вида аутентификации, по ЭП, некоторый OAuth и логин/пароль. Соответственно, предполагается по security, listener, 3 провайдера аутентификации и user-provider. Вот только, я задаюсь вопросом, а нафига мне это уже, если я работаю по REST, и не занимаюсь даже серверным рендерингом. Все что нужно это токен, listener не нужен как таковой (как мне кажется). Возможно и провайдер аутентификации лишний? Может, достаточно JWT и все?

Answer 1

[Илья Зябиров]

Security прекрасно может быть использован в REST, потому что он, по сути, просто предоставляет вам middleware для аутентификации пользователя, запускающееся при каждом запросе к вашему API. Саму же реализацию вы можете как выбрать из готовых, так и написать собственную. А UserProvider в свою очередь предоставляет вам доступ к объекту текущего пользователя внутри вашего кода, что весьма удобно.

Действительно, JWT достаточно, и никто не запрещает вам сделать реализацию без компонента security, однако его использование будет существенно удобнее при использовании этого бандла, который взаимодействует с security. В случае с ним вам не нужно будет даже писать реализацию middleware.

Comments

[Матвей Румынин]

Спасибо за совет.
Вам случайно не попадался пример использования security в REST? Очень хотелось бы посмотреть на код.
Особенно интересен вот такой момент. Симфони работает с пользователями в рамках сессии, т.е. юзер всегда аутентифицирован, например как аноним. Если приходит запрос на аутентификацию в качестве зарегистрированного пользователя, то этот запрос должен обрабатываться провайдером аутентификации или все же дойти до контроллера, и уже там? Вернее, перефразирую вопрос - какой вариант более корректный/понятный/правильный. Исходя из security way, по идее, первый, хотя он мне кажется немного избыточным. Хороших примеров бы почекать...

[Илья Зябиров]

Вот мой личный пример конфигурации Security для API. В первую очередь смотрите в самый низ: там под ключом api указан firewall для моего приложения (вернее, той его части, роуты которой соответствуют указанному шаблону). Все, что необходимо сделать и указать в конфигах вам - это создать UserProvider'а (или взять готовый), который будет реализовывать UserProviderInterface и методы которого будут возвращать UserInterface.

Насчет анонимных запросов: тут принцип тот же, что и с сессиями. Есть два варианта обработки анонимных запросов:

• первый - это создать firewall'ы для тех роутов, которые вы хотите сделать анонимными, как это сделано в том же конфиге, что я скинул (на мой взгляд, это не совсем правильно, т.к firewall'ы предназначены не совсем для этого)
  
• точно так же, как и в случае с сессиями использовать роли, предоставляемые Security (то есть просто указывать IS_AUTHENTICATED_ANONYMOUSLY для тех роутов, для которых это необходимо). В этом случае если запрос не является анонимным, но пользователь не предоставил токен, будет отдан 401 статус. А если роль текущего пользователя не соответствует указанной в конфиге - то 403.