путем обеспечения и конечной точки с ролью, работает для методов GET бот не POST, я получаю 403 Forbiden - PullRequest
Новая
       6

путем обеспечения и конечной точки с ролью, работает для методов GET бот не POST, я получаю 403 Forbiden

1 голос
/ 30 сентября 2019

Используя адаптер пружинной загрузки Keycloack (с защитой пружины), определяя типичный SecurityConfig (который расширяется от KeycloakWebSecurityConfigurerAdapter) и переопределяя метод "configure", я сталкиваюсь с проблемой при определении ролей доступа для конечной точки. , например, следующим образом: 

// typically access is defined something like this:
http
.authorizeRequests()
.antMatchers(GET, "/SOME_ENDPOINT").hasRole("SOME_ROLE")
....

Это работает для меня, но когда я меняю GET на POST, вдруг мой API отвечает - 403 Forbiden - для намеченной конечной точки (да, я тожеобновил метод HTTP самого метода аннотации @RequestMapping контроллера).

Что еще более странно, так это то, что я уже создал множество API-интерфейсов «только носитель», также защищенных через Keycloak + адаптер Springboot + безопасность пружины, которые не имеют никаких проблем при дифференциации этого типа доступа к конечной точке с помощью метода HTTP (Iиспользовали POST, PATCH, PUT и т. д.), и они работают нормально.

Есть ли какое-то ограничение для клиентов "не только на предъявителя", или я могу что-то пропустить? Любая обратная связь будет принята с благодарностью.

РЕДАКТИРОВАТЬ: Проблема, как представляется, связана с тем, что пружинная безопасность допускает только методы GET по умолчанию, и способ обойти это, как предложено вссылка, которой я поделился в комментариях, будет отключать csrf следующим образом: 

.csrf().disable()

Как также объяснено там, это деактивирует безопасность для всех конечных точек, что я не собираюсь делать. Я ожидал бы, что все вызовы метода http POST (или любого метода HTTP) будут обрабатываться и защищаться той же схемой, что и их аналог «GET».

1 Ответ

1 голос
/ 01 октября 2019

Короче говоря, для тех, кто сталкивается с подобной проблемой;Безопасность Spring по своей политике защиты CSRF (подделка межсайтовых запросов) по умолчанию создаст доступ HTTP 403, запрещенный для всех небезопасных запросов типа HTTP (POST, PUT, PATCH, DELETE).

Один из подходов, часто встречающихся здесь на форумах по переполнению стека, заключается в том, чтобы просто отключить проверки csrf для подмножества конечных точек, например: 

//@configure method of your Spring Security config

// disable some endpoints
http.csrf().ignoringAntMatchers("/URL_PREFIX_WHERE_CRSF_IS_IGNORED/*")....

// or disable all endpoints
http.csrf().disable()....

Лучшим подходом было быявно включайте токены csrf для любого запроса (и, таким образом, избегайте необходимости деактивировать проверки csrf).

PraveenKumar Lalasangi предоставила информацию о проблеме, как видно из комментариев, и вот подробная документация, связанная с включением / использованием токенов csrf:

https://docs.spring.io/spring-security/site/docs/3.2.5.RELEASE/reference/htmlsingle/#csrf-include-csrf-token

...