Подтвердить что ты не робот

Джерси CORS работает для GET, но не POST

My Jersey Запрос CORS не работает для POST, но работает для запросов GET. Заголовки сопоставляются с запросами Джерси, как показано на следующем скриншоте запроса GET на тот же ресурс.

Однако, выполняя POST для метода ниже, я заканчиваю тем, что XMLHttpRequest cannot load http://production.local/api/workstation. Origin http://workstation.local:81 is not allowed by Access-Control-Allow-Origin.

Вот скриншот сетевой активности: enter image description here

Сведения о неудавшемся запросе POST: enter image description here

Здесь мой ресурс:

@Path("/workstation")
@Consumes({MediaType.APPLICATION_JSON})
@Produces({MediaType.APPLICATION_JSON})
public class WorkstationResource {

    @InjectParam
    WorkstationService workstationService;

    @POST
    public WorkstationEntity save (WorkstationEntity workstationEntity) {
        workstationService.save(workstationEntity);
        return workstationEntity;
    }

    @GET
    @Path("/getAllActive")
    public Collection<WorkflowEntity> getActive () {
        List<WorkflowEntity> workflowEntities = new ArrayList<WorkflowEntity>();
        for(Workflow workflow : Production.getWorkflowList()) {
            workflowEntities.add(workflow.getEntity());
        }
        return workflowEntities;
    }
}

Мой фильтр CORS:

public class ResponseCorsFilter implements ContainerResponseFilter {

    @Override
    public ContainerResponse filter(ContainerRequest request, ContainerResponse response) {

        Response.ResponseBuilder responseBuilder = Response.fromResponse(response.getResponse());
        responseBuilder
                .header("Access-Control-Allow-Origin", "*")
                .header("Access-Control-Allow-Methods", "POST, GET, OPTIONS, PUT, DELETE, HEAD");

        String reqHead = request.getHeaderValue("Access-Control-Request-Headers");

        if(null != reqHead && !reqHead.equals(null)){
            responseBuilder.header("Access-Control-Allow-Headers", reqHead);
        }

        response.setResponse(responseBuilder.build());

        return response;
    }
}

Конфигурация My Jersey в моем основном классе:

//add jersey servlet support
ServletRegistration jerseyServletRegistration = ctx.addServlet("JerseyServlet", new SpringServlet());
jerseyServletRegistration.setInitParameter("com.sun.jersey.config.property.packages", "com.production.resource");
jerseyServletRegistration.setInitParameter("com.sun.jersey.spi.container.ContainerResponseFilters", "com.production.resource.ResponseCorsFilter");
jerseyServletRegistration.setInitParameter("com.sun.jersey.api.json.POJOMappingFeature", Boolean.TRUE.toString());
jerseyServletRegistration.setInitParameter("com.sun.jersey.config.feature.DisableWADL", Boolean.TRUE.toString());
jerseyServletRegistration.setLoadOnStartup(1);
jerseyServletRegistration.addMapping("/api/*");
4b9b3361

Ответ 1

Пока я думал, что это проблема CORS, оказывается, это проблема Джерси...

org.glassfish.grizzly.servlet.ServletHandler в строке 256 обрабатывается исключение...

    FilterChainInvoker filterChain = getFilterChain(request);
    if (filterChain != null) {
        filterChain.invokeFilterChain(servletRequest, servletResponse);
    } else {
        servletInstance.service(servletRequest, servletResponse);
    }
} catch (Throwable ex) {
    LOGGER.log(Level.SEVERE, "service exception:", ex);
    customizeErrorPage(response, "Internal Error", 500);
}

В моем журнале все, что я вижу, это service exception: без ничего после него. Когда я отлаживаю эту строку, я вижу ошибку javax.servlet.ServletException: org.codehaus.jackson.map.JsonMappingException: Conflicting setter definitions for property "workflowProcess": com.production.model.entity.WorkstationEntity#setWorkflowProcess(1 params) vs com.production.model.entity.WorkstationEntity#setWorkflowProcess(1 params), которая дает мне что-то, с чем я действительно могу работать.

Ответ 2

Трудно сказать и трудно отлаживать, так как это браузер, который создает эту ошибку при проверке ответа (заголовка).

Даже при очень близком осмотре ваш код выглядит отлично и разумно, за исключением того, что Access-Control-Allow-Headers установлен или может быть установлен дважды в filter(). Хотя RFC 2616 (HTTP 1.1) Раздел 4.2 в основном позволяет это, если выполняются определенные условия, я бы не стал играть в азартные игры здесь. У вас нет контроля над тем, как браузер X версии N справляется с этим.

Вместо того, чтобы дважды вводить один и тот же заголовок с разными значениями, добавьте второй набор значений в существующий заголовок.