签名网址和签名 Cookie 概览

借助 Cloud CDN 签名网址和签名 Cookie，您可以从 Google Cloud 分布在全球各地的缓存提供响应，即便在您要求对请求进行授权时也是如此。

Cloud CDN 签名网址和签名 Cookie 实现的目标相似：它们都可以控制对缓存的内容的访问。如果您希望从 Google Cloud 分布在全球各地的缓存提供内容，并且正在犹豫选择签名网址还是签名 Cookie，请参考下方的使用场景对比。

签名网址

签名网址提供可用于发出请求的有限权限和时间。

使用场景

在某些情况下，您可能希望您的用户无需拥有 Google 帐号便可访问 Cloud CDN 内容，不过您仍然想要根据应用的实际情况来控制访问权限。

在这种使用情景下，较为典型的做法是向用户提供允许其在有限时间内对该资源拥有读取访问权限的签名网址。您需要在创建签名网址时指定到期时间。在该网址到期之前或用于对该网址进行签名的密钥被轮替之前，知道该网址的任何人都可以访问资源。

在下列情况下，可以使用签名网址：

  • 您需要仅限用户访问个别文件，例如安装程序下载文件。

  • 您的用户所用的客户端应用不支持 Cookie。

签名网址的工作原理

签名网址允许客户端临时访问不公开的资源，而无需获得额外授权。为了达到这个目的，系统将对请求的选定元素执行哈希处理，并使用您生成的强随机密钥进行加密签名。

当请求使用您提供的签名网址时，系统会认为请求有权接收请求的内容。当 Cloud CDN 收到一个针对某项已启用的服务发出的请求，而该请求具有错误的签名时，将拒绝该请求，并且永远不会将该请求发送至您的后端进行处理。

一般来说，任何拥有某个签名网址的人都可以使用该网址。但是，签名网址通常只是为了让接收该网址的客户端使用。 为了缓解其他客户端使用该网址的风险，签名网址将在您选定的时间到期。为了避免签名网址被共享，请设置尽可能短的签名网址过期时间。

如何对网址签名

要对网址进行签名，您需要首先在后端服务或后端存储分区（或两者同时）中创建一个或多个加密密钥。然后，您可以使用 Google Cloud CLI 或您自己的代码对网址进行哈希签名和加密。

签名网址的处理

在后端启用签名网址处理功能后，Cloud CDN 会对带有签名网址的请求进行特殊处理。具体而言，具有 Signature 查询参数的请求会被视为带有签名。收到此类请求后，Cloud CDN 将验证以下内容：

  1. HTTP 方法是 GET、HEAD、OPTIONS 或 TRACE。
  2. 将 Expires 参数设置为将来的某个时间。
  3. 请求的签名与使用指定密钥计算得出的签名匹配。

如果其中任何一项检查失败，系统都会提供 403 Forbidden 响应。其他情况下，请求会被代理到后端，或从缓存中传送相应的响应。 （OPTIONS 和 TRACE 请求始终直接经由代理发送到后端，不会从缓存传送。）特定基础网址（Expires 参数之前的部分）的所有有效签名请求将共享相同的缓存条目。签名请求和未签名请求的响应不会共享缓存条目。系统将缓存并传送响应，直到达到您设置的过期时间为止。

系统通常会使用 Cache-Control 标头将需要签名请求的内容标记为不可缓存。为了使此类对象与 Cloud CDN 兼容（并且无需在后端做出更改），Cloud CDN 将在响应具有有效签名网址的请求时替换 Cache-Control 标头。Cloud CDN 将这些内容视为可缓存的内容，并会使用 Cloud CDN 配置中设置的 max-age 参数。传送的响应仍然具有后端生成的 Cache-Control 标头。

从 Google Cloud CLI 返回的网址或由您的自定义代码生成的网址可根据您的需求进行分发。我们建议仅对 HTTPS 网址进行签名，因为 HTTPS 提供的安全传输可防止签名网址中的签名部分遭到拦截。同样，您应该通过安全传输协议（例如 TLS/HTTPS）分发签名网址。

签名 Cookie

签名 Cookie 提供有限的权限和时间用于向一组文件发出请求。

使用场景

在下列情况下，可以使用签名 Cookie：

  • 您需要提供对多个受限文件的访问权限。

  • 您不想更改当前网址。

  • 您不希望在每次刷新授权时要更新网址后才能访问内容。

使用 HLS 和 DASH 流式传输媒体

如果您使用 HTTP Live Streaming (HLS) 或 Dynamic Adaptive Streaming over HTTP (DASH) 协议传送视频和音频内容，则通常会生成一个清单，其中包含指向视频和音频分段的网址列表。每个分段可以有多个实例，以便为客户端提供不同的编码（不同的编解码器、比特率或分辨率）。

虽然您可以使用 Cloud CDN 的签名网址对其中每个网址进行签名和访问授权，但针对每位用户动态生成所有可能的组合非常繁琐，也会增加源站的负载和应用的复杂性。

签名 Cookie 的目的就是解决这种问题。您可以为用户提供一个签名 Cookie，以授权他们访问与政策（网址前缀和过期日期）匹配的任何内容，而无需分别生成或签署多份媒体清单。您可以通过网页导航上的 JavaScript fetch () API 或原生应用中的其他后台机制来定期刷新用户访问权限。刷新用户访问权限的能力也让您可以缩短过期时间，加大用户共享受保护内容的难度。

您可以向具有多个浏览器客户端和支持 HTTP 通信的其他客户端（例如 Google 的 ExoPlayer 和 iOS 的 AVPlayer）的用户签发这些 Cookie。

二进制文件下载（游戏）

与媒体的流式传输相似，如果您提供游戏客户端下载，可以将大小达到数 GB 的大型补丁程序或游戏数据分成多个较小的块，以支持更精细的缓存、失效和并发机制。

这些块通常会在清单中列出。签名 Cookie 可让您仅向经过身份验证的用户授予对这些下载内容的访问权限，而无需修改清单文件，并且与签名网址一样，也不必放弃 Cloud CDN 缓存的好处。

签名 Cookie 的工作原理

配置和发布签名 Cookie 的过程分为三个步骤：

  • 为给定后端服务创建签名密钥。
  • 创建带有允许的网址前缀、过期时间、键名称和加密签名的 Cookie 值。
  • 在应用代码中签发 Cookie。

在请求中包含这些签名 Cookie 时，Cloud CDN 会对这些签名 Cookie 执行验证。

您可以防止用户在使用 Cloud Storage 存储分区时避开签名 Cookie 控制。为此，请为用户移除 allUsers 角色并授予 Cloud CDN 服务帐号对相应存储分区的读取访问权限，从而限制对于底层存储分区的访问。

同样，您的虚拟机实例也应验证其传送的每个签名请求上的签名。

注意事项和限制

  • 对于您的签名 Cookie 所需的任何同意征集要求和隐私权合规要求，您自行承担全部责任。签名 Cookie 由您（而非 Google）提供和管理。

  • 如果您同时使用签名网址和签名 Cookie 来控制对同一批文件的访问权限，并且查看者使用签名网址请求文件，则 Cloud CDN 会仅根据签名网址来决定是否将文件返回给查看者。Cloud CDN 仅在网址未签名的情况下才会考虑签名 Cookie。

  • 如果您已对自己的服务进行了签名请求配置，并且您的网址包含 Signature 查询参数，则 Cloud CDN 会尝试将您的网址解析为签名网址。如果 Cloud CDN 尝试将您的网址视为签名网址处理，而您并无此意图，则您的网址可能不是有效的签名网址，因此会被 Cloud CDN 拒绝。

  • 根据 RFC 6265 的规定，浏览器和其他客户端通常会对 Cookie 有所限制，通常是每个 Cookie 不超过 4 KB，每个网域中的 Cookie 总数不超过 50 个。他们要考虑从其网域发送的 Cookie 总负载。

  • Cloud CDN 限额和限制条件适用，包括每个后端最多 3 个签名请求密钥。

  • 签名请求与现有 Cloud CDN 请求的收费标准相同。但是，失败（被拒绝）的请求（例如在签名过期无效的情况下）仍会产生缓存查询费用。

后续步骤