我应该在OPTIONS请求之后的实际请求中向任何非允许的来源发送任何Access-Control-Allow-Origin标头吗？

Question

我对它是如何工作有一个大概的了解.如果请求的"origin"标头有效(允许),则返回相同的"ORIGIN"值

但我不知道:

1. 对于OPTIONS请求之后的实际请求,我是否需要包含我返回到客户端以进行预检请求的完全相同的Access-Control-Allow-Origin标头？当实际请求中存在"ORIGIN"标头时,服务器代码是否只需要执行此操作？(在下面的代码中,我没有检查请求是OPTIONS /预检请求还是实际请求,我假设相同的代码可以同时适用于两者并且没有任何损害).

(更多细节,因为"当请求的凭据模式为'include'时,响应中'Access-Control-Allow-Origin'标头的值不能是通配符'*',所以我需要来自的'ORIGIN值'要求重新回复.

2. 如果不允许使用ORIGIN,我应该返回什么？

   根本不包括Access-Control-Allow-Origin标头？
   或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

对于OPTIONS请求之后的实际请求,我是否需要包含我返回到客户端以进行预检请求的完全相同的Access-Control-Allow-Origin标头？

是的 - 也就是说,如果您要发回实际原始值而不是" *"通配符,那么原始值是导致OPTIONS请求成功的原因.因为如果发回不同于通配符的非通配符原始值OPTIONS,则会导致浏览器阻止客户端代码访问响应(因为实际原点不匹配).

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

是的,因为当在浏览器中运行的前端JavaScript代码使用XHR或Fetch API或来自某个JavaScript库的Ajax方法来发出跨源请求时,浏览器总是Origin会在请求中添加标头.并且Access-Control-Allow-Origin仅供浏览器使用.

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

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

如果不允许使用ORIGIN,我应该返回什么？
根本不包括Access-Control-Allow-Origin标头？

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

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

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

不,没有必要像这样发回空值.这并不意味着什么特别的.

或setHeader("Access-Control-Allow-Origin","null")？

绝对不要那样做.在许多情况下,浏览器将发送Origin带有该值的标头,null除非您有意要允许所有请求Origin: null访问服务器的响应,否则不要这样做.

有关详细信息,请参阅何时浏览器必须在内部将原点设置为将作为null答案的一部分进行序列化的值.当Firefox在POST请求中将Origin标头设置为null时？