Откуда Symfony Security гидратирует свой AuthorizationCheckerInterface?

Question

Я работаю над трехлетним программным обеспечением, которое опирается на Symfony Безопасность и сеансы для его авторизации. Недавно компания обратилась с просьбой о том, чтобы, пытаясь соединить несколько связанных систем, они хотели бы, чтобы наше приложение управляло своими сеансами с помощью Javascript веб-токенов, передаваемых ему защитой другого приложения.

Не точно зная, с чего начать, я начал с просмотра нашего файла SessionController. php. Этот файл в основном проверяет текущий сеанс и возвращает pass / fail, если такового нет. Так что было просто переключиться на использование JWT, потому что все, что мне нужно было, это найти повара ie и расшифровать его. Эта часть работает нормально.

То, что не работает нормально, это авторизация: вы можете видеть приложение, но даже кнопка входа в систему показывает, что вы не вошли в систему. В основном: пока у меня есть действующий токен, Symfony Безопасность еще не имела возможности увлажнить свои классы (я полагаю), чтобы позволить вызовам isGranted () работать правильно.

Таким образом, суть в том, что мы больше не используем Symfony войти - это обрабатывается в другом месте. Но когда приложение вызывается, оно должно как-то распознать, что аутентификация произошла в другом месте, и узнать, что оно должно делать.

Токен JWT содержит идентификатор пользователя, поэтому получение разрешений пользователя выглядит так, как будто быть тривиальным вопросом. Но что я не знаю, где происходит фактическое увлажнение классов безопасности?

Я рад предоставить примеры кода, но, поскольку это целое приложение, я не хотел перегружать сообщение с тем, что может оказаться бесполезным и очень длинным образцом кода.

Вот, однако, наш файл security.yaml, который, я уверен, будет актуален:

# To get started with security, check out the documentation:
# http://symfony.com/doc/current/book/security.html
security:
    role_hierarchy:
        ROLE_USER: []
        ROLE_EDITOR: [ROLE_USER]
        ROLE_ADMIN: [ROLE_EDITOR]
        ROLE_SUPER_EDITOR: [ROLE_EDITOR]
        ROLE_SUPER_USER: [ROLE_ADMIN, ROLE_SUPER_EDITOR, ROLE_ALLOWED_TO_SWITCH]

    encoders:
        App\Entity\User\User:
            algorithm: auto

    # http://symfony.com/doc/current/book/security.html#where-do-users-come-from-user-providers
    providers:
        local_db_provider:
            entity:
                class: App\Entity\User\User

        in_memory:
            memory: ~

    firewalls:
        # disables authentication for assets and the profiler, adapt it according to your needs
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false

        session_check:
            pattern: ^/session/check
            methods: [GET]
            security: false

        read_api:
            pattern: ^/api/
            methods: [GET]
            security: false

        main:
            pattern: ^/
            anonymous: true
            #stateless: true
            provider: local_db_provider
            user_checker: App\Security\UserChecker

            logout:
                path: /logout
                target: salt_index

            guard:
                authenticators:
                    - App\Security\LoginFormAuthenticator

    # with these settings you can restrict or allow access for different parts
    # of your application based on roles, ip, host or methods
    # http://symfony.com/doc/current/cookbook/security/access_control.htm
    # Note: Only the *first* access control that matches will be used
    access_control:
        #- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY, requires_channel: https }
        - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/logout, roles: IS_AUTHENTICATED_ANONYMOUSLY }
        - { path: ^/, roles: IS_AUTHENTICATED_ANONYMOUSLY }

Спасибо .