2016-01-09 1 views
2

У меня есть вопрос по конкретной проблеме, связанной с CORS: настройка конфигурации CORS на стороне сервера на JAX-RS что он работает правильно для GET, PUT и POST, я не смог заставить его работать с УДАЛЕНИЕ запросы.JAX-RS: Нет «Ошибка доступа-Control-Allow-Origin» Ошибка CORS только при удалении с помощью клиента Restangular

Я настроил фильтры запрос/ответ JAX-RS, как описано here и here:

для "предполетной OPTIONS" запросы:

@Provider 
@PreMatching 
public class CorsOptionsPreflightRequestFilter implements ContainerRequestFilter { 
    @Override 
    public void filter(ContainerRequestContext requestCtx) throws IOException { 
     if (requestCtx.getRequest().getMethod().equals("OPTIONS")) { 
      requestCtx.abortWith(Response.status(Response.Status.OK).build()); 
     } 
    } 
} 

Для реальных CORS обработки:

@Provider 
@PreMatching 
public class CorsResponseFilter implements ContainerResponseFilter { 
    @Override 
    public void filter(ContainerRequestContext requestCtx, ContainerResponseContext responseCtx) throws IOException { 
     responseCtx.getHeaders().add("Access-Control-Allow-Origin", "*"); 
     responseCtx.getHeaders().add("Access-Control-Allow-Credentials", "true"); 
     responseCtx.getHeaders().add("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS, HEAD"); 
     responseCtx.getHeaders().addAll("Access-Control-Allow-Headers", "origin, content-type, accept, authorization"); 
    } 
} 

Я тестирую Google Chrome с включенным the CORS plugin.

Опять же, GET, PUT и POST запросы работают отлично, но УДАЛИТЬ дает ошибку:

XMLHttpRequest cannot load http://localhost:8080/serverApplication/persons/3. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:9000' is therefore not allowed access. The response had HTTP status code 400. 

Примечание: Я заинтересован только в растворах с работой со стандартом JAX-RS, не от поставщика (например, RESTeasy, Spring).

Что мне не хватает?


редактировать 1:

Кроме того, при установке отладки точки останова в CorsResponseFilter#filter(), он никогда не будет достигнуто на DELETE запроса, но на GET/POST запросов это. Также DELETE хорошо работает при выполнении его с консоли curl.

редактировать 2:

Клиент написан на Restangular.

+0

Я не могу сказать вам, в чем проблема, но я реализовал то же самое несколько месяцев назад. См. Здесь: https://github.com/RobJinman/CorsFilter. Сопровождающие тесты гарантируют, что он соответствует этой спецификации (http://www.w3.org/TR/2014/REC-cors-20140116/) – RJinman

+0

@RJinman Обратите внимание, что текущая спецификация для CORS на самом деле https: //fetch.spec .whatwg.org /, и вы, вероятно, захотите (дважды) проверить это. Он получает исправления ошибок и другие обновления/уточнения, чтобы убедиться, что он остается в соответствии с текущими реализациями в браузерах. – sideshowbarker

ответ

2

Извините, неверный сигнал.

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

«магическое» решение сказать Restangular отправить DELETE запросы без тела, как объяснено в this issue:

RestangularProvider.setRequestInterceptor(function(elem, operation) { 
    if (operation === "remove") { 
    return undefined; 
    } 
    return elem; 
}) 

В противном случае, DELETE запросов вызвать 400 ошибку, которую я подозреваю, что браузер неправильно интерпретировать, как ошибка CORS, таким образом выводя над сообщением об ошибке CORS в консоли.