Spring Security - заголовок базовой аутентификации отправляется для всех URL-адресов, а не только для защищенной конечной точки - PullRequest
1 голос
/ 08 апреля 2019

В приложении Spring Security / Boot я настроил базовую аутентификацию для определенного шаблона URL:

http.antMatcher(StringUtils.join("myURL", "/**")).authorizeRequests().anyRequest().authenticated().and().httpBasic().realmName("realmName");

Это работает как чудо, поскольку, когда я запрашиваю URL этого шаблона, мне предлагаетсябраузером, чтобы предоставить учетные данные, и после этого я могу получить доступ к этой конечной точке.Однако после успешной авторизации для этой конечной точки браузер отправляет заголовок авторизации с маркером «Basic ...» даже для запросов на URL-адреса, которые не имеют ничего общего с настроенным в приведенном выше коде.Например, домашняя страница сайта.

Это вызывает срабатывание других механизмов авторизации веб-приложения, а именно keycloak, поскольку они ожидают допустимые токены внутри заголовка Authorization.Я знаю, что могу настроить keycloak таким образом, чтобы он не пытался интерпретировать заголовок авторизации, начинающийся с «Basic», но кажется, что основной причиной этой дилеммы является то, что заголовок get отправляется на запросы, которые непринадлежат к основному auth URL.

Есть ли способ сообщить Spring Security / браузеру / кому бы то ни было, что заголовок авторизации basic-auth следует включать в запрос только в том случае, если запрос относится к URL-адресу, совпадающему с шаблоном, которым был http-basicнастроен для?Разве это не должно быть стандартным поведением?

Примеры URL:

  • localhost: 8083 / myURL : я ожидаю, что браузер отправит заголовок аутентификации
  • localhost: 8083 / myURL / moreURL : я также ожидаю, что браузер отправит заголовок аутентификации
  • localhost: 8083 / someOtherURL : я не ожидаюбраузер для отправки заголовка аутентификации, , но он делает!
  • localhost: 8083 / someOtherURL / moreURL : То же самое, браузер неожиданно отправляет заголовок

1 Ответ

1 голос
/ 08 апреля 2019

В ваших приложениях должны использоваться разные каталоги и разные области, см. RFC 2617 :

2 Базовая схема аутентификации

[...]
Клиент ДОЛЖЕН предположить, что все пути на глубине или глубине последний символический элемент в поле пути Request-URI также находятся в пределах защитного пространства, заданного значением основной области текущий вызов. Клиент МОЖЕТ превентивно отправить соответствующий заголовок авторизации с запросами ресурсов в это пространство без получения другого запроса от сервера.

и см. Также Источник хрома :

// 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 обоим приложениям.

...