从 CORS 的角度来看，是否可以为多个前端提供一个基于 Cookie 的 API？答案

【问题标题】：Is a single Cookie Based API for multiple frontends possible from a CORS perspective?从 CORS 的角度来看，是否可以为多个前端提供一个基于 Cookie 的 API？
【发布时间】：2015-09-11 09:48:04
【问题描述】：

我最初编写了一个 REST API 来处理以前编写的移动应用程序。移动程序员要求我在登录时生成一个auth_token，他将作为每个需要身份验证的请求的标头传递。此 API 在 api.example.com 运行。

后来，我被委托编写一个与此 API 通信的 AngularJS 应用程序，所以我必须在后端使用 Access-Control-Allow 标头来使 OPTIONS 请求与 CORS 兼容 CORS 所以我的浏览器允许连接（看起来像 iOS 不查找此标头）。这个应用程序在one.example.com 运行。

现在，我必须编写第二个 AngularJS 应用程序，该应用程序将在 two.example.com 运行，第三个计划在不久的将来在 three.example.com 运行。

我的问题是我的Access-Control-Allow-Origin 标头看起来像这样：

Access-Control-Allow-Origin: http://one.example.com:80

* 是不允许的，我也无法将此标头设置为多个来源。据我所知，我有两个解决方案：

与当前的cookie-based 并行实施token-based 身份验证。我正在考虑this。这当然需要一些我愿意节省的时间。
向请求者发送标头或参数到 API 端点，在 OPTIONS 请求和服务器端识别应用程序，相应地生成 CORS 标头。我什至不知道这是否可能，这看起来很糟糕。

有更好的想法吗？

【问题讨论】：

API 使用什么语言？
@Yagiz PHP/Laravel。这有什么关系？

标签： angularjs api cookies cross-domain

【解决方案1】：

如果它们具有相同的来源，例如相同的域 (example.com) 或相同的子域（1.ex.example.com 和 2.ex.example.com），它们可以共享相同的 cookie。因为cookie是基于域本身的。

【讨论】：

浏览器会自动发出 OPTIONS 请求并在 Access-Control-Allow-Origin 标头中查找源集。源由模式 + 域 + 端口表示。如果这三个不是我正在使用的确切，则请求失败。那我是不是做错了什么？
否 @Mauro，OPTIONS 请求用于识别客户端可以使用的不同 HTTP 方法。因此，您应该从 API 端更改 CORS 设置。你应该写 *.example.com 作为你的 cookie 域来源。
这不起作用：XMLHttpRequest 无法加载 api.example.com/auth/login。 “Access-Control-Allow-Origin”标头的值“http://*.example.com:9002”不等于提供的来源。因此，不允许访问 Origin 'admin.example.com:9002'。
这有什么关系？那只是我的本地开发环境。我将 grunt 服务器设置为该端口，因此它不会发生冲突。