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，用于从 data.json 文件检索动态数据，该文件也托管在 example.com 上。我们希望处理来自我们的 AMP 页面的对我们的 data.json 文件的请求。这些请求可能来自同一来源（未缓存）的 AMP 页面，也可能来自不同来源（已缓存）的 AMP 页面。

允许的来源

根据我们从上面验证 CORS 请求中了解到的关于 CORS 和 AMP 的信息，在我们的示例中，我们将允许来自以下域的请求

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 页面获取请求

在以下场景中，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 页面获取请求

在以下场景中，缓存在 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 <请求-url> -H <自定义-标头> - I

测试来自同一来源的请求

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

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

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 标头是请求的一部分。

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

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