AMP 中的 CORS

许多 AMP 组件和扩展程序通过使用跨源资源共享 (CORS) 请求来利用远程端点。本文档解释了在 AMP 中使用 CORS 的关键方面。要了解 CORS 本身，请参阅 W3 CORS 规范。

- [为什么我自己的源需要 CORS？](#why-do-i-need-cors-for-my-own-origin-) - [为 CORS 请求利用 Cookie](#utilizing-cookies-for-cors-requests) - [AMP 中的 CORS 安全性](#cors-security-in-amp) - [验证 CORS 请求](#verify-cors-requests) - [1) 允许来自特定 CORS 源的请求](#1-allow-requests-for-specific-cors-origins) - [2) 允许同源请求](#2-allow-same-origin-requests) * [发送 CORS 响应标头](#send-cors-response-headers) - [Access-Control-Allow-Origin: <origin>](#access-control-allow-origin-origin) * [处理更改状态的请求](#processing-state-changing-requests) - [示例演练：处理 CORS 请求和响应](#example-walkthrough-handing-cors-requests-and-responses) - [在 AMP 中测试 CORS](#testing-cors-in-amp)

为什么我自己的源需要 CORS？

您可能会困惑为什么您自己的源的请求需要 CORS，让我们深入了解一下。

获取动态数据的 AMP 组件（例如，amp-form、amp-list 等）会向远程端点发出 CORS 请求以检索数据。如果您的 AMP 页面包含此类组件，您需要处理 CORS，以便这些请求不会失败。

让我们用一个例子来说明这一点

假设您有一个 AMP 页面，其中列出了带有价格的产品。要更新页面上的价格，用户单击一个按钮，该按钮从 JSON 端点检索最新价格（通过 amp-list 组件完成）。JSON 位于您的域上。

好的，所以页面是在我的域上，JSON 也在我的域上。我看不出有什么问题！

啊，但是您的用户是如何访问您的 AMP 页面的？他们访问的是缓存的页面吗？很有可能您的用户不是直接访问您的 AMP 页面，而是通过另一个平台发现了您的页面。例如，Google 搜索使用 Google AMP 缓存来快速呈现 AMP 页面；这些是来自 Google AMP 缓存的缓存页面，这是一个不同的域。当您的用户单击按钮以更新您页面上的价格时，缓存的 AMP 页面会向您的源域发送请求以获取价格，这是源之间不匹配（缓存 -> 源域）。要允许此类跨源请求，您需要处理 CORS，否则请求将失败。

好的，我该怎么办？

对于获取动态数据的 AMP 页面，请确保测试这些页面的缓存版本；不要只在您自己的域上进行测试。（请参阅下面的在 AMP 中测试 CORS 部分）
请按照本文档中的说明处理 CORS 请求和响应。

为 CORS 请求利用 Cookie

大多数使用 CORS 请求的 AMP 组件会自动设置凭据模式或允许作者选择启用它。例如，amp-list 组件从 CORS JSON 端点获取动态内容，并允许作者通过 credentials 属性设置凭据模式。

示例：通过 Cookie 在 amp-list 中包含个性化内容

<amp-list
  credentials="include"
  src="<%host%>/json/product.json?clientId=CLIENT_ID(myCookieId)"
>
  <template type="amp-mustache">
    Your personal offer: ${{price}}  </template>
</amp-list>

通过指定凭据模式，源可以在 CORS 请求中包含 Cookie，也可以在响应中设置 Cookie（受第三方 Cookie 限制的约束）。

浏览器中指定的相同第三方 Cookie 限制也适用于 AMP 中的凭据 CORS 请求。这些限制取决于浏览器和平台，但对于某些浏览器，只有当用户之前在第一方（顶部）窗口中访问过该来源时，该来源才能设置 Cookie。或者换句话说，只有在用户直接访问来源网站本身之后。鉴于此，通过 CORS 访问的服务不能默认假定它能够设置 Cookie。

AMP 中的 CORS 安全性

要确保您的 AMP 页面的请求和响应有效且安全，您必须

验证请求.
发送适当的响应标头.

如果您在后端使用 Node，则可以使用 AMP CORS 中间件，它是 AMP 工具箱的一部分。

验证 CORS 请求

当您的端点收到 CORS 请求时

验证 CORS Origin 标头是否为允许的来源（发布者的来源 + AMP 缓存）.
如果没有 Origin 标头，请检查请求是否来自同一来源（通过 AMP-Same-Origin）.

1) 允许来自特定 CORS 源的请求

CORS 端点通过 Origin HTTP 标头接收请求源。端点应仅允许来自以下来源的请求：(1) 发布者自己的来源；以及 (2) https://cdn.ampproject.org/caches.json 中列出的每个 cacheDomain 来源。

例如，端点应允许来自以下来源的请求

Google AMP 缓存子域：https://<发布者的域名>.cdn.ampproject.org
（例如，https://nytimes-com.cdn.ampproject.org）

有关 AMP 缓存 URL 格式的信息，请参阅以下资源

Google AMP 缓存概述

2) 允许同源请求

对于缺少 Origin 标头的同源请求，AMP 设置以下自定义标头

AMP-Same-Origin: true

当在同一来源（即，从非缓存 URL 提供的文档）上发出 XHR 请求时，AMP 运行时会发送此自定义标头。允许包含 AMP-Same-Origin:true 标头的请求。

发送 CORS 响应标头

验证 CORS 请求后，生成的 HTTP 响应必须包含以下标头

Access-Control-Allow-Origin: <origin>

此标头是 W3 CORS 规范的要求，其中 origin 是指通过 CORS Origin 请求标头允许的请求来源（例如，"https://<发布者的子域名>.cdn.ampproject.org"）。

尽管 W3 CORS 规范允许在响应中返回 * 的值，但为了提高安全性，您应该

如果存在 Origin 标头，请验证并回显 Origin 标头的值。

处理更改状态的请求

在您处理请求之前执行这些验证检查。此验证有助于提供针对 CSRF 攻击的保护，并避免处理不受信任的来源请求。

在处理可能更改系统状态的请求（例如，用户订阅或取消订阅邮件列表）之前，请检查以下内容

如果设置了 Origin 标头:

如果来源与以下值之一不匹配，请停止并返回错误响应
- <发布者的域名>.cdn.ampproject.org
- 发布者的来源（也就是您的来源）
其中 * 表示通配符匹配，而不是实际的星号 (*)。
否则，请处理请求。

如果未设置 Origin 标头:

验证请求是否包含 AMP-Same-Origin: true 标头。如果请求不包含此标头，则停止并返回错误响应。
否则，请处理请求。

示例演练：处理 CORS 请求和响应

在 CORS 请求中，需要考虑以下两种情况：

来自相同来源的请求。
来自缓存来源（来自 AMP 缓存）的请求。

让我们通过一个示例来演练这些场景。在我们的示例中，我们管理一个名为 example.com 的站点，该站点托管一个名为 article-amp.html 的 AMP 页面。该 AMP 页面包含一个 amp-list，用于从也托管在 example.com 上的 data.json 文件检索动态数据。我们希望处理来自我们 AMP 页面的对 data.json 文件的请求。这些请求可能来自同一来源（非缓存）的 AMP 页面，也可能来自不同来源（缓存）的 AMP 页面。

允许的来源

根据我们对 CORS 和 AMP 的了解（来自上面的验证 CORS 请求），对于我们的示例，我们将允许来自以下域的请求：

example.com --- 发布商的域
example-com.cdn.ampproject.org --- Google AMP 缓存子域

允许的请求的响应标头

对于来自允许的来源的请求，我们的响应将包含以下标头：

Access-Control-Allow-Origin: <origin>

这些是我们在 CORS 响应中可能包含的其他响应标头：

Access-Control-Allow-Credentials: true
Content-Type: application/json
Access-Control-Max-Age: <delta-seconds>
Cache-Control: private, no-cache

伪 CORS 逻辑

我们用于处理 CORS 请求和响应的逻辑可以简化为以下伪代码：

IF CORS header present
   IF origin IN allowed-origins
      allow request & send response
   ELSE
      deny request
ELSE
   IF "AMP-Same-Origin: true"
      allow request & send response
   ELSE
      deny request

CORS 示例代码

这是一个我们可以用来处理 CORS 请求和响应的 JavaScript 函数示例：

function assertCors(req, res, opt_validMethods, opt_exposeHeaders) {
  var unauthorized = 'Unauthorized Request';
  var origin;
  var allowedOrigins = [
    'https://example.com',
    'https://example-com.cdn.ampproject.org',
    'https://cdn.ampproject.org',
  ];
  var allowedSourceOrigin = 'https://example.com'; //publisher's origin
  // If same origin
  if (req.headers['amp-same-origin'] == 'true') {
    origin = sourceOrigin;
    // If allowed CORS origin & allowed source origin
  } else if (
    allowedOrigins.indexOf(req.headers.origin) != -1 &&
    sourceOrigin == allowedSourceOrigin
  ) {
    origin = req.headers.origin;
  } else {
    res.statusCode = 403;
    res.end(JSON.stringify({message: unauthorized}));
    throw unauthorized;
  }

  res.setHeader('Access-Control-Allow-Credentials', 'true');
  res.setHeader('Access-Control-Allow-Origin', origin);
}

注意：有关工作代码示例，请参阅 amp-cors.js。

场景 1：来自同一来源的 AMP 页面的 Get 请求

在以下场景中，article-amp.html 页面请求 data.json 文件；来源是相同的。

如果我们检查请求，我们会发现：

Request URL: https://example.com/data.json
Request Method: GET
AMP-Same-Origin: true

由于此请求来自同一来源，因此没有 Origin 标头，但存在自定义 AMP 请求标头 AMP-Same-Origin: true。我们可以允许此请求，因为它来自同一来源 (https://example.com)。

我们的响应标头将是：

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example.com

场景 2：来自缓存的 AMP 页面的 Get 请求

在以下场景中，缓存在 Google AMP 缓存上的 article-amp.html 页面请求 data.json 文件；来源不同。

如果我们检查此请求，我们会发现：

Request URL: https://example.com/data.json
Request Method: GET
Origin: https://example-com.cdn.ampproject.org

由于此请求包含 Origin 标头，我们将验证它是否来自允许的来源。我们可以允许此请求，因为它来自允许的来源。

我们的响应标头将是：

Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://example-com.cdn.ampproject.org

使用缓存的字体

Google AMP 缓存会缓存 AMP HTML 文档、图像和字体，以优化 AMP 页面的速度。在提高 AMP 页面速度的同时，我们也希望小心保护缓存的资源。我们将更改 AMP 缓存响应其缓存资源的方式，通常针对字体，通过尊重来源的 Access-Control-Allow-Origin 值。

过去的行为（2019 年 10 月之前）

当 AMP 页面从 @font-face src 属性加载 https://example.com/some/font.ttf 时，AMP 缓存将缓存字体文件，并使用通配符 Access-Control-Allow-Origin 以下方式提供该资源。

URL https://example-com.cdn.ampproject.org/r/s/example.com/some/font.tff
Access-Control-Allow-Origin: *

新的行为（2019 年 10 月及之后）

虽然当前的实现是宽松的，但这可能会导致从跨源站点意外使用字体。在此更改中，AMP 缓存将开始使用源服务器响应的完全相同的 Access-Control-Allow-Origin 值进行响应。要从缓存的 AMP 文档正确加载字体，您需要通过标头接受 AMP 缓存源。

一个示例实现如下：

function assertFontCors(req, res, opt_validMethods, opt_exposeHeaders) {
  var unauthorized = 'Unauthorized Request';
  var allowedOrigins = [
    'https://example.com',
    'https://example-com.cdn.ampproject.org',
  ];
  // If allowed CORS origin
  if (allowedOrigins.indexOf(req.headers.origin) != -1) {
    res.setHeader('Access-Control-Allow-Origin', req.headers.origin);
  } else {
    res.statusCode = 403;
    res.end(JSON.stringify({message: unauthorized}));
    throw unauthorized;
  }
}

例如，如果您想在 https://example.com/amp.html 中加载 /some/font.ttf，则源服务器应使用以下 Access-Control-Allow-Origin 标头进行响应。

如果您的字体文件可以从任何来源访问，则可以使用通配符 Access-Control-Allow-Origin 进行响应，AMP 缓存也会回显该值，这意味着它将使用 Access-Control-Allow-Origin: * 进行响应。如果您已经有此设置，则无需进行任何更改。

我们计划在 2019 年 10 月中旬左右进行此更改，并希望使用自托管字体的每位 AMP 发布商检查其是否受到影响。

推出计划

2019-09-30：版本包含对该更改应用到的域的更精确控制。此版本应在本周内推出。
2019-10-07：测试域将启用以进行手动测试。
2019-10-14：(但取决于测试的进展情况)：该功能将全面推出。

请关注相关的此处的 issue。

在 AMP 中测试 CORS

在测试 AMP 页面时，请确保包含来自 AMP 页面缓存版本的测试。

通过缓存 URL 验证页面

要确保您的缓存 AMP 页面正确呈现和工作：

在您的浏览器中，打开 AMP 缓存将用于访问您的 AMP 页面的 URL。您可以从 AMP By Example 上的此工具确定缓存 URL 格式。

例如：
- URL：https://amp.org.cn/documentation/guides-and-tutorials/start/create/
- AMP 缓存 URL 格式：https://www-ampproject-org.cdn.ampproject.org/c/s/www.ampproject.org/docs/tutorials/create.html
打开浏览器的开发人员工具，并验证是否没有错误以及所有资源是否已正确加载。

验证服务器响应标头

您可以使用 curl 命令来验证您的服务器是否正在发送正确的 HTTP 响应标头。在 curl 命令中，提供请求 URL 和您想要添加的任何自定义标头。

语法：curl <request-url> -H <custom-header> - I

测试来自同一来源的请求

在同源请求中，AMP 系统会添加自定义的 AMP-Same-Origin:true 标头。

这是我们的 curl 命令，用于测试从 https://amp.org.cn 到 examples.json 文件（在同一域上）的请求：

curl 'https://amp.org.cn/static/samples/json/examples.json' -H 'AMP-Same-Origin: true' -I

该命令的结果显示了正确的响应标头（注意：额外的信息已被修剪）：

HTTP/2 200
access-control-allow-headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token
access-control-allow-credentials: true
access-control-allow-origin: https://amp.org.cn
access-control-allow-methods: POST, GET, OPTIONS

测试来自缓存的 AMP 页面的请求

在非来自同一域（即缓存）的 CORS 请求中，origin 标头是请求的一部分。

这是我们的 curl 命令，用于测试从 Google AMP 缓存上的缓存 AMP 页面到 examples.json 文件的请求：

curl 'https://amp.org.cn/static/samples/json/examples.json' -H 'origin: https://ampbyexample-com.cdn.ampproject.org' -I

该命令的结果显示了正确的响应标头：

HTTP/2 200
access-control-allow-headers: Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token
access-control-allow-credentials: true
access-control-allow-origin: https://ampbyexample-com.cdn.ampproject.org
access-control-allow-methods: POST, GET, OPTIONS