更好地理解 Ajax CORS答案

【问题标题】：Better understanding Ajax CORS更好地理解 Ajax CORS
【发布时间】：2014-04-14 20:47:45
【问题描述】：

我有 3 个需要合作的域...
我的流程基本上是这样的：

“我可以”/“我应该”如何实现这种行为？

我在 B.com ajax 中设置了 xhrFields "withCredentials: true"，但是使用 fiddler 检查请求，没有发送任何 cookie...

Ps：我有点迷路了......如果需要额外的信息请询问！

【问题讨论】：

哪个 cookie 发往c.com？来自A 或C 自己的cookie 的cookie？
我需要A.com设置的coockie
Cookies 只会发送到原始域。如果您在a.com 上设置cookie，浏览器将不会将其发送到c.com。您可以在 a.com 上创建一个 Web 方法，将 cookie 值作为 JSON (Access-Control-Allow-Origin: b.com) 发送回，并使用类似方法允许在 c.com 上的 Web 方法上设置此 cookie。

标签： ajax cors

【解决方案1】：

看看我的回答here...

如果您设置withCredentials 标志，则请求“可能”被预检。这意味着浏览器在发送您的实际请求之前发送OPTIONS 请求。 OPTIONSrequest 的响应将决定是否允许/拒绝实际请求。

--- 编辑 ---

无论预检选项请求如何，带有withCredentials 标志的请求只有在响应标头带有Access-Control-Allow-Credentials 时才会成功，此外还允许请求尝试的来源、方法和任何必要或包含的标头制作。

这就是 CORS。所以在所有域（a、b、c 等）之间都是相同的。

【讨论】：

默认情况下，认证请求不会被预检。请求中 cookie 的存在不是确定请求是否将被预检的一部分。仅当请求包含非简单方法或非简单标头时才会预检。
我稍微修改了我的答案，但是withCredentials 标志表示该请求应该在服务器收到OPTIONS 请求以通知客户端是否按要求允许凭据的前提下进行按照规范和提到的here
不，这不是真的。 withCredentials 与请求是否被预检无关。我认为您误读/误解了规范。仅当请求包含非简单标头或非简单方法时，才会预检请求。例如，如果是带有简单标头的 GET 请求，则不会预检已认证的请求。在这种情况下，将发送一个请求（底层请求），并且服务器必须包含一个 Access-Control-Allow-Origin 标头和一个 Access-Control-Allow-Credentials 标头。您链接到的文章也证明了这一点。
无论如何，解决方法是确保响应包含正确的标头。
是的，我完全同意。