使用 Google Cloud Storage 和签名 URL 保护网页和所需资源？答案

【问题标题】：Securing a web page and required resources with Google Cloud Storage and signed urls?使用 Google Cloud Storage 和签名 URL 保护网页和所需资源？
【发布时间】：2013-08-07 00:19:58
【问题描述】：

我正在尝试保护对我的应用引擎 Web 应用程序上优质内容的访问。内容是一个Articulate 模块，它是一个带有数十个相关的javascript、音频和视频资源的player.html。我正在尝试使用 Google Cloud Storage 来托管内容。

我的想法是，当通过我的应用程序进行身份验证并具有适当访问权限的用户请求高级内容时，我的应用程序可以签署一个指向 player.html 的 url。我不确定的是如何处理所有相关的资源文件？签名的 url 很简单，可以保护单个文件，但是文件组呢？我是否必须对所有内容的 url 进行签名，或者是否可以让一个签名的 url 允许访问相关文件？

ACL 不是一个选项，因为我推出了自己的身份验证，而不是使用 oAuth 和 Google 帐户。

任何想法或替代策略将不胜感激。

更新 8.7.13

经过更多的思考和研究，我想知道按照here的说明将GCS存储桶配置为网站。

如果我对文档的理解正确，我会创建一个 CNAME 来将来自我的自定义域 content.example.com 的请求指向 c.storage.googleapis.com，并且通过这个 CNAME 到达的请求就像它们一样被提供一个静态网页。有谁知道以这种方式提供的文件有哪些访问控制（如果有的话）？如果以这种方式提供的文件不是公开的，是否也需要签名/ACL？

【问题讨论】：

标签： google-cloud-storage

【解决方案1】：

很遗憾，您的选择有限。以下是两个想法，但它们都有相当大的缺点。不幸的是，两者都不是超级棒。

混淆

使所有相关资源均可公开访问，并保存在无法猜测的子目录下。用户将使用签名 URL 加载受保护的根资源，其中包括指向可公开访问的辅助资源的链接。缺点：子资源不安全，任何知道 URL 的一方都可以下载。可能的缓解措施：定期轮换子资源目录。

Appengine 重定向

更改包括通过您的 appengine 应用路由所有资源，该应用将使用自己的方案进行身份验证并重定向到每个子资源的新签名 URL。缺点：通过 appengine 有很多额外的跃点。因此，例如，player.html 将包含一个名为“https://yourapp.appspot.com/resources/movie.mov”的电影，它会点击您的 appengine 应用程序，然后该应用程序会进行身份验证，然后重定向到签名的“https://storage.googleapis.com/yourbucket/movie.mov?signaturestuff”

【讨论】：