Обработчик запроса OPTIONS должен вызываться перед обработчиком API - PullRequest
Новая
       6

Обработчик запроса OPTIONS должен вызываться перед обработчиком API

0 голосов
/ 28 апреля 2019

У меня есть работающий компонент @RestController, который выдает веб-конечные точки API.

Это одна из этих конечных точек 

  @CrossOrigin
  @GetMapping(API_VERSION + PLAYER + METHOD_FETCH + "/{uid:^[0-9]*$}")
  public Player fetchPlayer(@PathVariable("uid") String uid) {
    return mongoTemplate.findById(uid, Player.class);
  }

Теперь при использовании моего приложения Vue.js я вызываю эту конечную точку.Проблема заключается в том, что клиентская библиотека axios http превращает запрос get , имеющий заголовки аутентификации, в запрос options для проверки сервера на фактический доступ.

Теперь янеобходимо использовать этот запрос options и включить его для CORS .Поэтому я сделал следующее: 

@RestController
@Log
@RequestMapping("/**")
public class AuthenticationEndpoint {
  @CrossOrigin
  @RequestMapping(method = RequestMethod.OPTIONS)
  public void handleOptionRequest(){
    log.info("option request handled");
  }
}

Я сопоставляю его с каждым URL, чтобы он "должен" перехватывать каждый запрос OPTIONS.Но это не так.При наличии 

GET http://{{host}}:80/api/v0.1/player/fetch/4607255831
Authorization: Basic MTIzNTM2NDMyNDphYmMxMjM=

Более конкретная веб-конечная точка API обрабатывается до обработчика OPTIONS.Как я могу на самом деле поместить обработчик OPTIONS перед другими в Spring MVC?Я хочу, чтобы он действовал как перехватчик

ИЛИ

Каков наилучший способ достижения желаемого поведения?Я чувствую, что пытаюсь найти лучшее решение.

1 Ответ

0 голосов
/ 28 апреля 2019

Как я могу на самом деле поместить обработчик OPTIONS перед остальными в Spring MVC? Я хочу, чтобы он действовал как перехватчик.

Вы можете создать компонент класса, который реализует интерфейс Filter и присвоить ему высокий порядок: 

@Component
@Order(1)
public class RequestInterceptor implements Filter {

    @Override
    public void doFilter
      ServletRequest request, 
      ServletResponse response, 
      FilterChain chain) throws IOException, ServletException {

        HttpServletRequest req = (HttpServletRequest) request;
        String httpMethod = req.getMethod();
        if(HttpMethod.OPTIONS.name().equals(httpMethod)){
           //do something here before reaching the method handler
        }
        chain.doFilter(request, response);

    }

    // other methods 
}

Или вы можете расширить OncePerRequestFilter.java и выполнить ту же проверку, что и выше, в методе doFilterInternal.

EDIT

Если вы хотите контролировать, следует ли продолжать обработку запроса на подачу или нет, вы можете использовать HandlerInterceptor:

HandlerInterceptor вызывается перед соответствующим HandlerAdapter запускает выполнение самого обработчика. Этот механизм может быть используется для большой области аспектов предварительной обработки, например, за проверки авторизации или обычное поведение обработчика, например локаль или тема изменения. Его главная цель состоит в том, чтобы учесть повторяющиеся код обработчика.

HandlerInterceptor в основном похож на сервлет Фильтр, но в отличие от последнего он просто позволяет настраивать предварительная обработка с возможностью запрета на выполнение Сам обработчик и пользовательская пост-обработка. Фильтры более мощные, например, они позволяют обмениваться объектами запроса и ответа которые передаются по цепочке. Обратите внимание, что фильтр настраивается в web.xml, HandlerInterceptor в контексте приложения. 

@Comonent
public class LoggerInterceptor extends HandlerInterceptorAdapter {
     @Override
     public boolean preHandle(HttpServletRequest request,
                          HttpServletResponse response,
                          Object handler)
                   throws Exception{
         // do checks and decide wether to complete or to stop here
         // true if the execution chain should proceed with the next interceptor or the handler itself. 
        // Else, DispatcherServlet assumes that this interceptor has already dealt with the response itself.
        return true;
     }
     // other methods
}
...