Миграция с Spring Boot 1.4 на 1.5 с OAuth2

Question

Попытка обновить "старое" приложение Sprint Boot + Spring OAuth2 в 1.3.x, до, мы надеемся, версии 2.1.5.RELEASE или чего бы то ни было в то время.

Я просто пытаюсьсделать это один шаг за один раз. Я получил его с Spring Boot 1.3 до 1.4, и все, кажется, работает нормально.

Проблема с 1.4 до 1.5.По сути, мои веб-службы, защищенные моим сервером ресурсов, похоже, совсем не пострадали (я полагаю, что они возвращаются к рабочему процессу WebSecurity / User, возвращая перенаправление 302 на страницу входа).

Из журналов, которые яЯ вижу, что он даже не пытается сопоставить мой запрос с шаблоном, который я определил в моем ResourceServerConfigurerAdapter .

[...].AntPathRequestMatcher::matches::::::Checking match of request : '/v1/private/user'; against '/oauth/token'
...(same as above against other paths)...
[...].OrRequestMatcher::matches::::::No matches found

Другими словами, ни одно из этих «против» не имеет ничего общего с тем, что я настроилв конфигурации (HttpSecurity http), которая просто:

http
        .authorizeRequests()
        .antMatchers( "/v1/**" )
        .permitAll()
        .and().csrf().disable()

Тот же код в Sprint Boot 1.4 работает нормально, и он проверяет входящий запрос по этому шаблону / v1 / **, как и ожидалось.

Я прочитал заметки о выпуске Spring Boot 1.5 и думаю, что это может быть связано с this :

[...] с использованием @EnableWebSecurityотключит все автоматические настройки веб-безопасности, что позволит вам получить полный контроль.

Помните , приложение отлично работает в Spring Boot 1.3 ид 1.4.Эта проблема возникает при обновлении до версии 1.5.

Обновление 06/07: Autowired FilterChainProxy для просмотра задействованных фильтров и сравнения между двумя версиями Spring Boot.И если я правильно понимаю, это проблема.В версии 1.4.x порядок цепочек фильтров внутри FilterChainProxy в основном:

1. OAuth auth * цепочка фильтров, соответствие / oauth / token, / oauth / token_key и /oauth/check_token.
2. OAuth "защищенные" конечные точки.Я считаю, что материал, определенный в HttpSecurity в конфигурации сервера ресурсов.Цепочка фильтров здесь использует для этого средство сопоставления NotOAuthRequestMatcher.Я считаю, что важным фильтром в этой цепочке является OAuth2AuthenticationProcessingFilter, который делает все волшебство.
3. Last - это цепочка фильтров, использующая сопоставление AnyRequestMatcher.Будет соответствовать любому запросу, и важным фильтром в этой цепочке является UsernamePasswordAuthenticationFilter.Я верю, что это «рабочий процесс пользователя».

Теперь при использовании 1.5.x каким-то образом переключаются # 2 и # 3 выше.Это объясняет, почему ни один из моих запросов веб-службы не соответствует моим конечным точкам веб-службы.Не понимаю, почему порядок испортился (я не использую @Order в моей конфигурации).Пора заглянуть в @Order, наверное ...

Кто-нибудь еще сталкивался с этой проблемой?Как ты решил это?

Answer 1

Конечно же, хитрость заключалась в том, чтобы добавить следующее в мое расширение WebSecurity ConfigurerAdapter :

@Order(SecurityProperties.ACCESS_OVERRIDE_ORDER)

Найден ответ по SO здесь .