最佳方法:Access-Control-Allow-Origin多个源域

Question

这个问题之前已经在这里提出并给出了一系列好的答案,主要是: Access-Control-Allow-Origin多个原始域？

但是,在应该采用的核准方法方面似乎存在着解释上的差距.通过W3文档阅读,我认为这是一种指导冲突.

首先,我们在许多先前的答案中看到了给出答案的正确方法,该答案规定主机服务器必须动态回显给定的"Origin"(如果它出现在预定义的"白名单"上). http://www.w3.org/TR/cors/#resource-implementation

然而,所使用的许多答案和方法也提到了空格分隔列表,该列表也可以用作将多个"起源"传递给允许的方法.如果我们看一下http://www.w3.org/wiki/CORS_Enabled上的另一篇W3文档,我们在页面的第一部分看到了一个例子:

 Access-Control-Allow-Origin: http://example.com:8080 http://blah.example.com http://foo.example.com

在这两种方法中,我同样很乐意将其纳入其中,但是可能会有大量的URL需要列入其中,因此我希望确保我第一次正确地执行此操作.如果有人对上述两种方法有任何见解,我将非常感谢您在选择中听到决定,以及是否有可能错过的推荐方法的明确指南.

Answer 1

关于这个的文档似乎暗示它允许多个来源与空格分隔列表,但这不是它实际意味着什么.以下是我可以收集的对您的问题最明确的答案:Access-Control-Allow-Origin标题应该与标题相同Origin,只要您想允许它.

您发送回客户端的白名单不是因为技术上客户端可以发送空格分隔的原始列表,以便服务器可以验证请求.因此,原因列表的目的是因为请求可能来自多个来源(即,请求是跨域重定向的).即使从未生成空格分隔列表(至少通过Firefox),测试套件也可以通过不同的重定向可能性轻松观察此行为.

这在您提供的第一个链接的W3C文档中有较低的说明:

Access-Control-Allow-Origin标头指示是否可以通过在响应中返回Origin请求标头的值"*"或"null"来共享资源.ABNF:

Access-Control-Allow-Origin ="Access-Control-Allow-Origin"":" origin-list-or-null | "*"

实际上,origin-list-or-null生产受到更多约束.它不是允许以空格分隔的原点列表,而是单个原点或字符串"null".

并再次在原始列表的定义.此外,它显示如果您确实希望允许字符串"null"作为原点,它无论如何都无法嵌入到原始列表中.

因此,请坚持使用基于客户端Origin标头的动态生成的标头,以及是否与您的白名单相匹配.