Spring Security — заголовок базовой аутентификации отправляется для всех URL-адресов, а не только для защищенной конечной точки
В приложении Spring Security/Boot я настроил базовую аутентификацию для определенного шаблона URL:
http.antMatcher(StringUtils.join("myURL", "/**")).authorizeRequests().anyRequest().authenticated().and().httpBasic().realmName("realmName");
Это работает как шарм, например, когда я запрашиваю URL-адрес этого шаблона, браузер предлагает мне предоставить учетные данные, и после этого я могу получить доступ к этой конечной точке. Однако после успешной авторизации для этой конечной точки браузер отправляет заголовок Authorization с токеном «Basic…» даже для запросов к URL-адресам, которые не имеют ничего общего с настроенным в приведенном выше коде. Например, главная страница веб-сайта.
Это приводит к срабатыванию других механизмов авторизации веб-приложения, а именно keycloak, поскольку они ожидают действительных токенов внутри заголовка авторизации. Я знаю, что могу настроить keycloak таким образом, чтобы он не пытался интерпретировать заголовок авторизации, начинающийся с «Basic», но похоже, что основная причина этой дилеммы заключается в том, что заголовок отправляется для запросов, которые не относятся к URL-адресу базовой аутентификации.
Есть ли способ, которым я могу сообщить Spring Security/браузеру/кому-либо, что заголовок авторизации basic-auth должен быть включен в запрос только в том случае, если запрос предназначен для URL-адреса, соответствующего шаблону, для которого был настроен http-basic? Разве это не должно быть стандартным поведением в любом случае?
Примеры URL:
- локальный: 8083/мой URL : я ожидаю, что браузер отправит Заголовок аутентификации
- локальный: 8083/мой URL/большеURL : я также ожидаю, что браузер отправит Заголовок аутентификации
- локальный хост: 8083/someOtherURL : я не ожидаю, что браузер отправит заголовок аутентификации, но это так!
- локальный хост: 8083/someOtherURL/moreURL : То же самое, браузер отправляет Заголовок неожиданно
Ответы 1
Ваши приложения должны использовать разные содержащие каталоги и разные области, см. RFC 2617:
2 Basic Authentication Scheme
[...]
A client SHOULD assume that all paths at or deeper than the depth of the last symbolic element in the path field of the Request-URI also are within the protection space specified by the Basic realm value of the current challenge. A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
и см. также Источник хрома:
// Helper to find the containing directory of path. In RFC 2617 this is what // they call the "last symbolic element in the absolute path". // Examples: // "/foo/bar.txt" --> "/foo/" // "/foo/" --> "/foo/"
В вашем случае содержащийся каталог — это / для одного из ваших приложений. Другое приложение находится в подпути этого содержащего каталога. Следовательно, ваш браузер упреждающе отправляет один и тот же заголовок Authorization обоим приложениям.