cors - 我是否应该在 OPTIONS 请求之后的实际请求中将任何 Access-Control-Allow-Origin header 发送到不允许的来源？

Question

我对它的工作原理有一个大概的了解。如果请求的“origin” header 有效(允许)，我将返回相同的“ORIGIN”值

但我不知道:

1. 对于 OPTIONS 请求之后的实际请求，我是否需要包含与我针对预检请求返回给客户端的完全相同的 Access-Control-Allow-Origin header ？服务器代码是否只需要在实际请求中存在“ORIGIN” header 时才需要执行此操作？ (在下面的代码中，我没有检查该请求是 OPTIONS/预检请求还是实际的请求，我假设相同的代码可以适用于两者而不会造成任何损害)。

(更多详细信息，因为“当请求的凭据模式为‘include’时，响应中‘Access-Control-Allow-Origin’ header 的值不能是通配符‘*’，”所以我需要 ORIGIN将请求中的值放回到响应中。

如果 ORIGIN 不允许，我应该返回什么？

根本不包含 Access-Control-Allow-Origin header ？
或 setHeader("Access-Control-Allow-Origin", ""),或 setHeader("Access-Control-Allow-Origin", "null")？

public class CORSResponseFilter implements ContainerResponseFilter {

@Override
public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
    MultivaluedMap<String, Object> headers = responseContext.getHeaders();

    String origin = requestContext.getHeaderString("Origin"); 


String origin = requestContext.getHeaderString("Origin");

    URL originUrl = null;
    try {
        if (StringUtils.hasText(origin)) {
            originUrl = new URL(origin);
            
            Pattern hostAllowedPattern = Pattern.compile("(.+\\.)*mydomain\\.com", Pattern.CASE_INSENSITIVE);

            if (hostAllowedPattern.matcher(originUrl.getHost()).matches()) {
                headers.add("Access-Control-Allow-Origin", origin);
            } else {
                headers.add("Access-Control-Allow-Origin", "");
            }
            headers.add("Vary", "Origin");
        }

        headers.add("Access-Control-Allow-Credentials", "true");
        headers.add("Access-Control-Allow-Methods", "GET, POST, DELETE, PUT");
        headers.add("Access-Control-Allow-Headers",

Answer 1

For the actual request following the OPTIONS request, do I need to include the exact same Access-Control-Allow-Origin header that I returned to the client for the preflight request?

是的 - 也就是说，如果您发送回实际的原始值而不是“*”通配符，并且该原始值是导致 OPTIONS 请求的原因成功。因为如果您发送回的非通配符原始值与 OPTIONS 成功的值不同，则会导致浏览器阻止客户端代码访问响应(因为实际的原始值不匹配) )。

Should the server code only need to do this when there is an "ORIGIN" header present in the actual request?

是的，因为当浏览器中运行的前端 JavaScript 代码使用 XHR 或 Fetch API 或某些 JavaScript 库中的 Ajax 方法发出跨源请求时，浏览器总是添加一个 Origin header 的请求。 Access-Control-Allow-Origin 仅由浏览器使用。

因此，在这种情况下，将 Access-Control-Allow-Origin 发送回未在请求中发送 Origin 的非浏览器工具是没有意义的，这只是您发送出去的浪费的字节。

当然，有人可以使用curl或任何非浏览器工具向服务器发送请求，并手动向请求添加Origin header 。但这没关系 - 在这种情况下，他们得到的响应与您发送到浏览器的响应相同。所以这实际上对测试很有帮助。

What should I return if the ORIGIN is not allowed?
not including the Access-Control-Allow-Origin header at all?

是的。对于这些情况，根本不要发回 Access-Control-Allow-Origin 响应 header 。这就是缺少 header 的语义:如果服务器没有发送 Access-Control-Allow-Origin 响应 header ，则意味着服务器没有选择允许来自正在运行的前端代码的跨源请求浏览器，因此应用默认的同源策略。

也就是说，通过不发送 Access-Control-Allow-Origin 响应 header ，服务器告诉浏览器:“请照常使用默认同源策略并禁止访问来自发送此请求的源的所有前端 JavaScript 代码的响应。”

or setHeader("Access-Control-Allow-Origin", ""),

不，永远不需要发回这样的空值。这并没有什么特别的意义。

or setHeader("Access-Control-Allow-Origin", "null")?

绝对不要这样做。在很多情况下，浏览器会发送值为 null 的 Origin header ，除非您有意允许所有带有 Origin: null 的请求要访问服务器的响应，请不要这样做。

有关详细信息，请参阅答案的当浏览器必须在内部将 origin 设置为将被序列化为 null 的值时 When does Firefox set the Origin header to null in POST requests?