Блог

Главная - Вопросы по программированию - Spring Data REST CORS — как обрабатывать запрос параметров предполетной проверки?

Spring Data REST CORS — как обрабатывать запрос параметров предполетной проверки?

#spring #cors #spring-data-rest #http-options-method

#spring #cors #spring-data-rest #http-options-метод

Вопрос:

Я использую Spring Data REST для создания RESTful API. До сих пор мой HTML-графический интерфейс для этой RESTful-службы обслуживался с того же Tomcat, и у меня не было проблем с перекрестными исходными запросами.

Теперь я хочу обслуживать статические файлы с другого сервера. Это означает, что API находится на другом домене / порту. Браузеры отправят запрос ПАРАМЕТРОВ, чтобы получить заголовки управления доступом с сервера. К сожалению, Spring Data REST не обрабатывает эти запросы параметров и даже возвращает HTTP 500.

Я попытался создать пользовательский контроллер, который обрабатывает все запросы параметров

 @Controller
@RequestMapping(value = "/**", method = RequestMethod.OPTIONS)
public class OptionsController {

    @RequestMapping
    public ResponseEntity options() {
        return new ResponseEntity<Void>(HttpStatus.OK);
    }
}

Который работал для ПАРАМЕТРОВ, но затем все остальные запросы (например, GET) перестали работать.

Запросы ПАРАМЕТРОВ включаются с помощью параметра сервлета dispatchOptionsRequest dispatcher.

Комментарии:

1. Вы пробовали фильтр CORS от Tomcat?

2. Нет. Проблема исправлена в SDR в следующей версии. Мы просто использовали обратный прокси для сопоставления запросов с тем же доменом и портом.

Ответ №1:

tl; dr: в настоящее время Spring Data REST вообще не отвечает OPTIONS на запросы.

Возможно, стоит открыть тикет в нашем JIRA.

Браузеры отправят запрос ПАРАМЕТРОВ, чтобы получить заголовки управления доступом с сервера.

Это где-то указано? Если это так, было бы здорово, если бы в описании билета была ссылка на эту спецификацию.

Несколько комментариев относительно вашего подхода к обходному пути:

  1. @RequestMapping на контроллере метод переопределяет method атрибут и, как ожидается, теперь соответствует всем методам HTTP, поэтому вы видите, что все запросы перехвачены. Итак, вам также нужно определить OPTIONS как HTTP-метод там (или, может быть, вместо сопоставления классов).
  2. Вы не возвращаете какой-либо Allow заголовок, который является основной целью OPTIONS в первую очередь.
  3. Интересно, имеет ли смысл подход в целом, поскольку будет сложно рассуждать о поддерживаемых методах HTTP в целом.

Комментарии:

1. Спасибо за ответ! Я попробовал 1), должен был опубликовать это. Не сработало. Как только я регистрирую свой контроллер, метод экспорта данных REST не работает. Заголовки добавляются в фильтр. Пункт 3, ну, я думаю, что CORS является распространенной проблемой и должен поддерживаться, особенно для REST API.

2. Я открыл jira.spring.io/browse/DATAREST-333 . Включены ссылки на w3c и mozilla.

3. @OliverGierke Я заметил, что Spring Data REST устанавливает заголовок разрешить методы, используя org.springframework.http. HttpHeaders. РАЗРЕШИТЬ, для которого установлено значение «Разрешить». В соответствии с этой рекомендацией W3C , имя заголовка должно быть Access-Control-Allow-Methods . Почему это несоответствие?

4. В настоящее время мы просто реализуем метод HTTP OPTIONS, как определено в спецификации.

Ответ №2:

Просто установите параметр dispatchOptionsRequest true в диспетчер для обработки Options вызовов методов в реализацию WebApplicationInitializer .

 ServletRegistration.Dynamic dispatcher = container.addServlet("dispatcher", new DispatcherServlet(applicationContext));

dispatcher.setInitParameter("dispatchOptionsRequest", "true");                

dispatcher.setLoadOnStartup(1);
dispatcher.addMapping("/*");