我是否应该在选项请求之后的实际请求中向不允许的源发送任何访问控制允许源标题？

Question

我对它是如何工作的有一个大致的想法。如果请求的源头有效（允许），则返回相同的ORIGIN值

但我不知道：

1. 对于OPTIONS请求之后的实际请求，我是否需要包括与我返回给客户端的预飞行请求完全相同的访问控制允许源标头？服务器代码应该只在实际请求中存在“ORIGIN”标头时才需要这样做吗？（在下面的代码中，我没有检查请求是OPTIONS/起飞前请求还是实际请求，我假设相同的代码可以适用于两者而没有伤害）。

（更多详细信息，因为“当请求的凭据模式为“include”时，响应中的“Access Control Allow Origin”头的值不能是通配符“*”，所以我需要请求中的原始值放回响应中。

如果不允许使用ORIGIN，我应该退回什么？

根本不包括访问控制允许原点标头？
或setHeader（“访问控制允许原点”），或setHeader（“访问控制允许原点”，“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

对于OPTIONS请求之后的实际请求，是否需要包含与我为飞行前请求返回给客户端的完全相同的Access Control Allow Origin头？

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

服务器代码是否只需要在实际请求中存在“ORIGIN”头时执行此操作？

是的，因为当浏览器中运行的前端JavaScript代码使用XHR或从某个JavaScript库获取API或Ajax方法来发出跨源请求时，浏览器总是向请求添加origin头。而访问控制允许源代码仅由浏览器使用。

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

当然，有些人可以使用curl或任何非浏览器工具向服务器发送请求，并手动向请求添加Origin标头。但没关系——在这种情况下，他们会得到的响应和你发送到浏览器的响应是一样的。所以这实际上对测试很有帮助。

如果不允许原点，我应该返回什么？
根本不包括访问控制允许原点标头？

对对于这些情况，只需根本不发回访问控制允许源站响应头即可。这就是缺少标头的语义：如果服务器不发送Access Control Allow Originresponse标头，这意味着服务器没有选择允许来自前端代码运行浏览器的跨源请求，因此默认的同源策略适用。

也就是说，通过不发送Access Control Allow Origin响应头，服务器告诉浏览器：“请像往常一样使用默认的同源策略，并禁止发送此请求的源站的所有前端JavaScript代码访问此响应。”

或setHeader（“访问控制允许原点）”，

不，永远不需要像那样发回空值。这并不意味着什么特别的。

或setHeader（“访问控制允许原点”、“空”）？

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

有关详细信息，请参阅When浏览器必须在内部将origin设置为一个值，该值将被序列化为null答案的一部分。在POST请求中，Firefox何时将origin头设置为null？