Spring Security блокирует запросы POST, несмотря на SecurityConfig

ПЕРЕД отключение CSFR как способ решения этой проблемы, пожалуйста, проверьте ресурсы на Ответ Мохда Васима, чтобы лучше понять, почему это важно, и иметь представление о том, как его можно правильно настроить. Как RCaetano сказал, CSFR здесь, чтобы помочь нам от атак, и его не следует отключать вслепую.

Поскольку в этом ответе все еще объясняются 2 проблемы на мои исходные вопросы, я оставлю его как отмеченный ответ, чтобы информировать о возможных проблемах с CSFT и маршрутами безопасности, но не воспринимайте это буквально.

В SecurityConfiguration.java было 2 проблемы, из-за которых он работал некорректно.

Хотя сообщение об ошибке 403 Forbidden не содержало никаких сообщений, указывающих на причину сбоя (см. Пример ниже), оказывается, что это произошло из-за включения CSRF. Отключение позволило обрабатывать запросы POST и DELETE.

{
    "timestamp": "2018-06-26T09:17:19.672+0000",
    "status": 403,
    "error": "Forbidden",
    "message": "Forbidden",
    "path": "/routeB"
}

Также выражение, используемое в antMatched(HttpMethod, String) для RouteB, было неверным, потому что /routeB/* ожидает, что он будет иметь что-нибудь после /. Правильная конфигурация - /routeB/**, поскольку присутствует больше путей может (или нет).

исправленоSecurityConfiguration.java - это

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS).and().
        authorizeRequests().antMatchers(HttpMethod.GET, "/**").hasAnyRole("ADMIN", "USER")
                           .antMatchers(HttpMethod.POST, "/routeA/**").hasAnyRole("ADMIN", "USER")
                           .antMatchers(HttpMethod.POST, "/routeB/**").hasRole("ADMIN")
                           .antMatchers(HttpMethod.DELETE, "/routeB/**").hasRole("ADMIN").and().
        requestCache().requestCache(new NullRequestCache()).and().
        httpBasic().authenticationEntryPoint(authenticationEntryPoint).and().
        cors().and().
        csrf().disable();
}

Source:StackOverflow em Português

Его простая проблема с включенным CSRF, которая не разрешает запросы POST. Я столкнулся с той же проблемой, вот решение: (Объяснил)

@Override
protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()
            .antMatchers(HttpMethod.POST,"/form").hasRole("ADMIN")  // Specific api method request based on role.
            .antMatchers("/home","/basic").permitAll()  // permited urls to guest users(without login).
            .anyRequest().authenticated()
            .and()
        .formLogin()       // not specified form page to use default login page of spring security
            .permitAll()
             .and()
        .logout().deleteCookies("JSESSIONID")  // delete memory of browser after logout

        .and()
        .rememberMe().key("uniqueAndSecret"); // remember me check box enabled.

    http.csrf().disable();  **// ADD THIS CODE TO DISABLE CSRF IN PROJECT.**
}

Над кодом:

http.csrf().disable();

решит проблему.

Cross-site request forgery is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform.

В вашем случае отключение защиты CSRF подвергает пользователя этой уязвимости.

Note: If it was pure Rest API with O-Auth protection then CSRF was not needed. Should I use CSRF protection on Rest API endpoints?

Но в вашем случае, когда пользователь входит в систему, создается сеанс и в ответ возвращается cookie, и без токена CSRF Злоумышленник может использовать его и выполнить CSRF.

Было бы неплохо отключать CSRF, вместо этого вы можете настроить свое приложение на возврат токена CSRF в заголовках ответов, а затем использовать его во всех ваших последующих вызовах изменения состояния.

Добавьте эту строку кода в свой SecurityConfiguration.java

// CSRF tokens handling
http.addFilterAfter(new CsrfTokenResponseHeaderBindingFilter(), CsrfFilter.class);

CsrfTokenResponseHeaderBindingFilter.java

public class CsrfTokenResponseHeaderBindingFilter extends OncePerRequestFilter {
    protected static final String REQUEST_ATTRIBUTE_NAME = "_csrf";
    protected static final String RESPONSE_HEADER_NAME = "X-CSRF-HEADER";
    protected static final String RESPONSE_PARAM_NAME = "X-CSRF-PARAM";
    protected static final String RESPONSE_TOKEN_NAME = "X-CSRF-TOKEN";

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, javax.servlet.FilterChain filterChain) throws ServletException, IOException {
        CsrfToken token = (CsrfToken) request.getAttribute(REQUEST_ATTRIBUTE_NAME);

        if (token != null) {
            response.setHeader(RESPONSE_HEADER_NAME, token.getHeaderName());
            response.setHeader(RESPONSE_PARAM_NAME, token.getParameterName());
            response.setHeader(RESPONSE_TOKEN_NAME, token.getToken());
        }

        filterChain.doFilter(request, response);
    }
}

Сервер формы ответа заголовка:

Обратите внимание, что теперь у нас есть токен CSRF в заголовке. Это не изменится, пока не истечет сеанс. Также прочтите: CSRF-защита Spring Security для служб REST: на стороне клиента и на стороне сервера для лучшего понимания.