Pull to refresh

Comments 5

Хм, ожидал что вы сделаете через систему аутентификации, а не через события
Это аутентификация. К тому же, надо сказать, не по канону сделанная.
Более правильно было бы сделать через Security. Это сложнее (сам долго разбирался), но гибче. А для активации созданного провайдера в любом нужном разделе приложения достаточно в security.yml к файрволу, который закрывает ваш API дописать одну строчку вида:
    firewalls:
        main:
            pattern:             /api/(.*)
            # Та самая строчка:
            your_provider: ~
По api-keys есть пример на самом сайте симфони, через штатный компонент security: symfony.com/doc/current/cookbook/security/api_key_authentication.html
В принципе он очень просто адаптируется, если нужны ограниченные по времени жизни токены — нужно просто вынести токены в отдельную сущность, как вы это сделали в статье, но саму аутентификацию все же лучше делать штатными средствами.
В данном посте как бы аутентификация описана, а не авторизация. Причем, как правильно заметил skobkin, не по канону.

[капитан]
Вообще, в плане безопасности приложение должно обеспечить два процесса — авторизация (register/login/logout) и аутентификацию.
[/капитан]

С этой точки зрения было бы интересно увидеть изящную реализацию этих частей приложения в виде стороннего бандла (двух бандлов?) с этим фукнционалом, которое можно легко интегрировать в приложение _без_ авторизации и аутентификации, а также с возможностью подстроить процесс под свои нужды. symfony даёт возможность реализовать это достаточно топорно (через перегрузку вендорного решения) и через события. Сам приступал к этой идее, пока что похвастаться почти нечем, кроме — github.com/hanovruslan/api-key-project

P.S.: карма не позволяет ссылки ставить :)
авторизация (register/login/logout)

Так-то, по сути, это и есть аутентификация. Авторизация — это работа с правами доступа, когда пользователь уже аутентифицирован. В Symfony это Voters, Roles.
Sign up to leave a comment.

Articles