Добрый день.
Перевожу проект на symfony ^6
composer update "symfony/*" --with-all-dependencies
result :
[critical] Uncaught Error: Class "Gesdinet\JWTRefreshTokenBundle\GesdinetJWTRefreshTokenBundle" not found

composer require gesdinet/jwt-refresh-token-bundle
result :
Problem 1
   - Root composer.json requires gesdinet/jwt-refresh-token-bundle ^0.12.0 -> satisfiable by gesdinet/jwt-refresh-token-bundle[v0.12.0].
   - gesdinet/jwt-refresh-token-bundle v0.12.0 requires symfony/framework-bundle ~3.4|~4.0|~5.0 -> found symfony/framework-bundle[v3.4.0, ..., v3.4.47, v4.0.0, ..., v4.4.34, v5.0.0, ..., v5.4.1] but it conflicts with your root composer.json require (6.0.*).

> gesdinet/jwt-refresh-token-bundle v0.12.0 requires symfony/framework-bundle ~3.4|~4.0|~5.0

> but it conflicts with your root composer.json require (6.0.*).

бандл не саппортит 6 симфу. Либо помоги им добавить саппорт, либо жди

После отработки firewall, удаляю токен и инвалидирую сессию. если пользователь на публичной странице, то она просто грузится, если на приватной (требуемая роль указана в комменте над контроллером), то происходит перепдресация на ллгин страницу - это тоже правильно. но закрытые в security.yml - access_control страницы показываются клиенту. здесь не происходит перееадресация только при повторной загрузке.

вариант с переадресацией на саму себя не рассматриваю.
повторный вызов firewall->onKernelRequest($event) делает переадресацию, как надо. но я не уверен в отсутствии подводных камней

Для чего удалять токен после firewall?

это oauth токен. при его обновлении, может выясниться, что он уже не действительный.

access_control проверяется в том же firewall listener, если удалить токен после него логично что никто повторно проверять не будет.
хз что за проблема у тебя, но решать её надо по другому

вот жеж. токен мне нужен, т. к. в нем лежит  oauth refresh token. запрос к oauth за новым access токенлм может не пройти, т. к., например, админ убил сессию.
и в данный момент валидный токен превращается в тыкву. можно конечно редиректить на себя, но решение так себе

поддержу @grachevko вы что-то городите не то, советую пересмотреть не это конкретное тех решение, а более архитектурное решение что вы делаете

напишите о изначальных условиях и целях

все достаточно просто. логинюсь я через oaurh2 keycloak (hwi/oauth-bundle)  server. локально сохраняютчя только данные юзера, которые перезаписываются, в случае их изменения на keycloak сервере.
этот OAuthToken отличается от стандартного наличием срока годности, и прочих oauth токенов - access, refresh и т. д.
как только истекает срок годности (у нас 5мин, у гугла - 1час) нужно идти на сервер oauth, за новым токеном, и может получиться, что в новом токене по каким либр причинам отказано. здесь хотелось бы юзера локально разлогинить,без переадресаций

а зачем логинить/разлогинить? клоака же за все отвечает, зачем дублируете ее функцию?

либо есть юзер, либо нет
не врубаюс

вам прилетает токен, вы его секретным ключом читаете и если валидный — пускаете, если нет — не пускаете
что за логины/разлогины?

не валидный — 403 и пусть идет заново логиниться, получать новый

через клоаку, юзер может быть залогинен на 10 сайтах. суперадмин на клоаке удаляет все сессии юзера и запрещает ему логинится. в течении 5 минут юзер должен вылететь со всех сайтов.

в принципе я нашел способ - через compiler pass внедрить своего слушателя, который срабатывает сразу после @security.context_listener.X
и обновляет либо резетит токен.

Дык это... У тебя должен быть листенер, который при каждом запросе токен проверяет в кк

а продлевать токен на бэкэнде - это хуита какая-то. Если токен истек, это проблема клиента что с этим делать. Либо запросить рефреш, либо выкинуть

при каждом запросе проверяется срок годности токена - это да.
На keycloak 1 запрос в 5мин