java - 如何使用带有Jersey的JAX-RS处理CORS

Question

我正在开发一个Java脚本客户端应用程序，在服务器端我需要处理CORS，以及我用JERSEY用JAX-RS编写的所有服务。
我的代码：

@CrossOriginResourceSharing(allowAllOrigins = true)
@GET
@Path("/readOthersCalendar")
@Produces("application/json")
public Response readOthersCalendar(String dataJson) throws Exception {  
     //my code. Edited by gimbal2 to fix formatting
     return Response.status(status).entity(jsonResponse).header("Access-Control-Allow-Origin", "*").build();
}

截至目前，我收到错误消息在请求的资源上没有“ Access-Control-Allow-Origin”标头。因此，不允许访问源'http://localhost:8080'。”

请协助我。

感谢和问候
佛陀

Answer 1

注意：请务必阅读底部的UPDATE


@CrossOriginResourceSharing是CXF批注，因此不适用于Jersey。

对于Jersey，要处理CORS，通常只使用ContainerResponseFilter。球衣1和2的ContainerResponseFilter有点不同。由于您尚未提及您使用的是哪个版本，因此我将同时发布两者。

球衣2

import java.io.IOException;
import javax.ws.rs.container.ContainerRequestContext;
import javax.ws.rs.container.ContainerResponseContext;
import javax.ws.rs.container.ContainerResponseFilter;

@Provider
public class CORSFilter implements ContainerResponseFilter {

    @Override
    public void filter(ContainerRequestContext request,
            ContainerResponseContext response) throws IOException {
        response.getHeaders().add("Access-Control-Allow-Origin", "*");
        response.getHeaders().add("Access-Control-Allow-Headers",
                "origin, content-type, accept, authorization");
        response.getHeaders().add("Access-Control-Allow-Credentials", "true");
        response.getHeaders().add("Access-Control-Allow-Methods",
                "GET, POST, PUT, DELETE, OPTIONS, HEAD");
    }
}

如果使用包扫描来发现提供程序和资源，则@Provider批注应为您进行配置。如果没有，那么您将需要在ResourceConfig或Application子类中显式注册它。

用于向ResourceConfig显式注册过滤器的示例代码：

final ResourceConfig resourceConfig = new ResourceConfig();
resourceConfig.register(new CORSFilter());
final final URI uri = ...;
final HttpServer httpServer = GrizzlyHttpServerFactory.createHttpServer(uri, resourceConfig);

  对于Jersey 2.x，如果在注册此过滤器时遇到问题，这里有一些资源可能会有所帮助
  
  
  Registering Resources and Providers in Jersey 2
  What exactly is the ResourceConfig class in Jersey 2?
  


球衣1

import com.sun.jersey.spi.container.ContainerRequest;
import com.sun.jersey.spi.container.ContainerResponse;
import com.sun.jersey.spi.container.ContainerResponseFilter;

public class CORSFilter implements ContainerResponseFilter {
    @Override
    public ContainerResponse filter(ContainerRequest request,
            ContainerResponse response) {

        response.getHttpHeaders().add("Access-Control-Allow-Origin", "*");
        response.getHttpHeaders().add("Access-Control-Allow-Headers",
                "origin, content-type, accept, authorization");
        response.getHttpHeaders().add("Access-Control-Allow-Credentials", "true");
        response.getHttpHeaders().add("Access-Control-Allow-Methods",
                "GET, POST, PUT, DELETE, OPTIONS, HEAD");

        return response;
    }
}

web.xml配置，可以使用

<init-param>
  <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
  <param-value>com.yourpackage.CORSFilter</param-value>
</init-param>

或者您可以执行ResourceConfig

resourceConfig.getContainerResponseFilters().add(new CORSFilter());

或使用@Provider批注进行程序包扫描。



编辑

请注意，上述示例可以改进。您将需要更多地了解CORS的工作原理。请参阅here。首先，您将获得所有响应的标题。这可能是不希望的。您可能只需要处理印前检查（或选项）。如果您想查看实现更好的CORS过滤器，可以查看RESTeasy CorsFilter的源代码



更新

因此，我决定添加一个更正确的实现。上面的实现是惰性的，并且将所有CORS标头添加到所有请求中。另一个错误是，由于它只是一个响应筛选器，因此请求仍在处理中。这意味着，当预检请求进入时（这是一个OPTIONS请求），将没有实现OPTIONS方法，因此我们将得到405响应，这是不正确的。

这是它应该如何工作的。因此，有两种类型的CORS请求：简单请求和preflight requests。对于简单请求，浏览器将发送实际请求并添加Origin请求标头。浏览器期望响应具有Access-Control-Allow-Origin标头，表示允许来自Origin标头的来源。为了将其视为“简单请求”，它必须满足以下条件：


是以下方法之一：


得到
头
开机自检

除了浏览器自动设置的标题外，该请求可能仅包含以下手动设置的标题：


Accept
Accept-Language
Content-Language
Content-Type
DPR
Save-Data
Viewport-Width
Width

Content-Type标头的唯一允许值为：


application/x-www-form-urlencoded
multipart/form-data
text/plain



如果该请求不满足所有这三个条件，则发出预检请求。这是在发出实际请求之前向服务器发出的OPTIONS请求。它将包含不同的Access-Control-XX-XX标头，并且服务器应使用自己的CORS响应标头来响应这些标头。以下是匹配的标题：

                 Preflight Request and Response Headers
+-----------------------------------+--------------------------------------+
|  REQUEST HEADER                   |  RESPONSE HEADER                     |
+===================================+======================================+
|  Origin                           |  Access-Control-Allow-Origin         |
+-----------------------------------+--------------------------------------+
|  Access-Control-Request-Headers   |  Access-Control-Allow-Headers        |
+-----------------------------------+--------------------------------------+
|  Access-Control-Request-Method    |  Access-Control-Allow-Methods        |
+-----------------------------------+--------------------------------------+
|  XHR.withCredentials              |  Access-Control-Allow-Credentials    |
+-----------------------------------+--------------------------------------+

使用Origin请求标头，该值将是源服务器域，并且响应Access-Control-Allow-Header应该是相同的地址或*以指定允许所有源。
如果客户端尝试手动设置不在上述列表中的任何标头，则浏览器将设置Access-Control-Request-Headers标头，该值是客户端尝试设置的所有标头的列表。服务器应使用Access-Control-Allow-Headers响应标头进行响应，该值是其允许的标头列表。
浏览器还将设置Access-Control-Request-Method请求标头，其值为请求的HTTP方法。服务器应使用Access-Control-Allow-Methods响应头进行响应，其值是其允许的方法的列表。
如果客户端使用XHR.withCredentials，则服务器应使用Access-Control-Allow-Credentials响应头（值为true）进行响应。 Read more here。


综上所述，这是一个更好的实现。尽管这比上面的实现更好，但是它仍然不如我链接到的RESTEasy one，因为该实现仍然允许所有起源。但是，与上述仅向所有请求添加CORS响应标头的过滤器相比，此过滤器在遵守CORS规范方面做得更好。注意，您可能还需要修改Access-Control-Allow-Headers以匹配您的应用程序允许的标头。在此示例中，您可能想要o从列表中添加或删除一些标头。

@Provider
@PreMatching
public class CorsFilter implements ContainerRequestFilter, ContainerResponseFilter {

    /**
     * Method for ContainerRequestFilter.
     */
    @Override
    public void filter(ContainerRequestContext request) throws IOException {

        // If it's a preflight request, we abort the request with
        // a 200 status, and the CORS headers are added in the
        // response filter method below.
        if (isPreflightRequest(request)) {
            request.abortWith(Response.ok().build());
            return;
        }
    }

    /**
     * A preflight request is an OPTIONS request
     * with an Origin header.
     */
    private static boolean isPreflightRequest(ContainerRequestContext request) {
        return request.getHeaderString("Origin") != null
                && request.getMethod().equalsIgnoreCase("OPTIONS");
    }

    /**
     * Method for ContainerResponseFilter.
     */
    @Override
    public void filter(ContainerRequestContext request, ContainerResponseContext response)
            throws IOException {

        // if there is no Origin header, then it is not a
        // cross origin request. We don't do anything.
        if (request.getHeaderString("Origin") == null) {
            return;
        }

        // If it is a preflight request, then we add all
        // the CORS headers here.
        if (isPreflightRequest(request)) {
            response.getHeaders().add("Access-Control-Allow-Credentials", "true");
            response.getHeaders().add("Access-Control-Allow-Methods",
                "GET, POST, PUT, DELETE, OPTIONS, HEAD");
            response.getHeaders().add("Access-Control-Allow-Headers",
                // Whatever other non-standard/safe headers (see list above) 
                // you want the client to be able to send to the server,
                // put it in this list. And remove the ones you don't want.
                "X-Requested-With, Authorization, " +
                "Accept-Version, Content-MD5, CSRF-Token, Content-Type");
        }

        // Cross origin requests can be either simple requests
        // or preflight request. We need to add this header
        // to both type of requests. Only preflight requests
        // need the previously added headers.
        response.getHeaders().add("Access-Control-Allow-Origin", "*");
    }
}

要了解有关CORS的更多信息，建议阅读Cross-Origin Resource Sharing (CORS)上的MDN文档