В приложении Spring Secuity / Boot у меня есть несколько @ Configuration аннотированных конфигураций, которые расширяют WebSecurityConfigurerAdapter .В одной из этих конкретных конфигураций я хочу защитить определенный URL с помощью базовой аутентификации.Я делаю это, переопределяя configure (final HttpSecurity) и используя antMatcher ("myURL") на объект HttpSecurity , за которым следует обычная цепочка авторизации и httpBasic () .
Но для настройки базовой аутентификации весной также необходимо, чтобы ваша конфигурация переопределила configure (final authnticationManagerBuilder auth) , где вы настраиваете механизм аутентификации, как я понимаю.В моем случае это простая inMemoryAuthentication () , с выбранным пользователем и паролем.Теперь я знаю, что некоторые другие конфигурации в проекте настраивают остальные URL-адреса с помощью более сложного механизма аутентификации, который реализует единый вход.Я не совсем уверен, что моя конфигурация, которая мешает AuthenticationManagerBuilder , как-то мешает этим другим механизмам?
Я ожидаю, что, поскольку в configure (final HttpSecurity) Я использую antMatcher ("myURL") , эта конфигурация создаст SecurityFilterChain с моим конкретным логика inMemoryAuthentication () (где-то глубоко в пружинном фильтре, который обрабатывает базовую аутентификацию) и что эта цепочка будет использоваться только для запросов, соответствующих шаблону "myURL".Я ожидаю, что моя новая конфигурация не затронет другие цепочки фильтров, созданные другими существующими конфигурациями и их более сложные механизмы аутентификации.Моя новая inMemoryAuthentication никогда не должна играть там никакой роли.Это правильно?