Когда приложение Spring возвращает ответ 403 или 401 до достижения точки останова внутри контроллера или сервиса, проблема может быть не в логике, которую разработчик хочет проверить, а в предшествующем выполнению запроса уровне авторизации. IntelliJ IDEA предлагает способ проверить фактические правила защиты в работающем приложении, а затем временно предоставить запросу идентичность и права во время сеанса отладки без изменения SecurityConfig или перезапуска приложения.
Функция является частью плагина Spring Debugger в IntelliJ IDEA Ultimate и доступна начиная с версии 2026.2. Security inlays отображаются по умолчанию во время работы отладчика — независимо от того, работает ли приложение локально или на удалённой JVM.
Сначала узнайте, что именно требует маршрут
Интерфейс в редакторе или HTTP-файле отображает требования конечной точки, основанные на ролях и разрешениях, включая правила, построенные с использованием hasRole и hasAuthority. IntelliJ IDEA при этом опирается не только на чтение файлов конфигурации, но и проверяет фактическую SecurityFilterChain внутри JVM после инициализации контекста Spring. Это важно, когда на итоговый результат влияют несколько SecurityFilterChain, порядок сопоставления, активные профили или условная регистрация конфигурации.
Если определённое правило невозможно преобразовать в список ролей, как бывает в некоторых пользовательских реализациях AuthorizationManager, правило отображается как неизвестное состояние со ссылкой на соответствующий код конфигурации защиты. В этом случае автоматическое открытие на основе списка ролей недоступно, и обращение к SecurityConfig остаётся необходимым.
Временное открытие маршрута во время сеанса отладки
Действие Unlock предоставляет два варианта. Первый передаёт запрос как аутентифицированный с набором ролей, необходимых для маршрута; он подходит, когда разработчик хочет протестировать логику контроллера или сервиса за защищённым маршрутом. Второй позволяет указать имя пользователя и пользовательский список разрешений, например admin с ROLE_ADMIN и ROLE_MANAGER, чтобы проверить поведение приложения с определённым набором прав.
При выполнении действия отладчик создаёт объект TestingAuthenticationToken внутри SecurityContext работающего приложения. Проверки hasRole и hasAuthority, а также SecurityContextHolder.getContext().getAuthentication() и параметры Principal или Authentication видят идентичность и права, заданные разработчиком. Действие не изменяет код приложения или файлы конфигурации, а открытые маршруты исчезают после перезапуска приложения, включая перезапуск внутри процесса через Spring Boot DevTools, или при ручной блокировке маршрута.
Воздействие не ограничивается запросом, отправленным из IntelliJ IDEA. Открытие GET для определённого маршрута влияет на любого клиента, обращающегося к тому же URI и использующего тот же HTTP-метод, например curl, Postman или браузер. Если в определении контроллера открыт шаблон маршрута, это может распространяться на все значения, соответствующие шаблону. Поэтому следует снова заблокировать маршрут или завершить сеанс отладки сразу после окончания работы, особенно если приложение доступно по сети.
Что не обходит Unlock?
Действие не отключает Spring Security полностью и не обходит защиту CSRF. Если запрос типа POST, PUT или DELETE требует действительный токен CSRF, CsrfFilter по-прежнему сможет его отклонить. Кроме того, область действия ограничена авторизацией конечных точек через AuthorizationFilter в стеке Servlet; Spring WebFlux, использующий AuthorizationWebFilter, не поддерживается.
Прямого интерфейса для отображения или открытия требований защиты на уровне методов, таких как @PreAuthorize, @PostAuthorize и @Secured, нет. Тем не менее права, внедрённые в SecurityContext, впоследствии могут быть прочитаны перехватчиком защиты методов, поэтому защищённый с помощью @PreAuthorize вызов сервиса может пройти, если предоставленные права удовлетворяют его условию. Это не означает, что IntelliJ IDEA открыла защиту самого метода: проверка прочитала тот же контекст искусственной аутентификации.
Ограничения идентичности и интеграция с инструментами тестирования
Идентичность, создаваемая отладчиком, представляет собой текстовое имя пользователя внутри TestingAuthenticationToken, а не UserDetails приложения или пользовательский тип объекта пользователя. Поэтому параметр с аннотацией @AuthenticationPrincipal может вернуть значение null; это известная проблема с номером IDEA-389767, которая затрагивала версию 2026.2 на момент публикации материала.
В качестве типа параметра можно использовать Principal или Authentication, однако зависимость от конкретного типа, например JwtAuthenticationToken, может привести к IllegalStateException, поскольку внедрённый объект не относится к этому типу. Также могут отличаться результаты или завершаться ошибкой части, зависящие от claims, credentials, идентичности, связанной с сеансом, или определённого типа токенов аутентификации.
Открытие работает с запросами из встроенного .http-файла, а также из curl, Postman и тестовых фреймворков при условии, что работающим является то же приложение, в котором был открыт маршрут. В автоматизированных рабочих процессах или процессах, зависящих от агентов искусственного интеллекта, программного ключа для выполнения операции сейчас нет. JetBrains планирует добавить инструмент MCP и связанную с ним возможность в версии 2026.3, однако текущая версия требует первого ручного щелчка внутри IDE.
Почему эта практика важна?
Практическая ценность заключается не в отключении защиты, а в изоляции уровня авторизации от логики, которую разработчик хочет протестировать, без сохранения временных изменений в файлах конфигурации, которые можно забыть и перенести в другую среду. При этом открытие является временным изменением безопасности в работающем процессе, а не локальной имитацией, ограниченной запросом из IDE. Поэтому его следует рассматривать как инструмент отладки с контролируемой областью действия, а не как замену настоящему тестированию аутентификации; перед использованием необходимо проверить маршрут, метод и затронутых клиентов.
Также следует учитывать, что функция не записывает сообщение в журналы и не предоставляет индикатор через Actuator при открытии маршрута в удалённом приложении. Согласно материалу, проверить состояние можно только через интерфейс в IDE, подключённой к приложению. При отсутствии необходимости Security inlays можно отключить с помощью параметра spring.debugger.security.enabled в Registry IntelliJ IDEA.