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：<来源>](#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 缓存的缓存页面，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：<来源>

此标头是 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 示例代码

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

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：（但取决于测试的进展）：该功能将普遍推出。

请关注相关的此处的问题。

在 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