Google Storage 或 Amazon S3 或 Google App Engine BlobStore答案

【问题标题】：Google Storage or Amazon S3 or Google App Engine BlobStoreGoogle Storage 或 Amazon S3 或 Google App Engine BlobStore
【发布时间】：2011-09-27 01:18:14
【问题描述】：

我将使用 Google App Engine 构建一个网站。我的公共网站包含数千张图片。我想将这些图片存储在云端：Google Storage 或 Amazon S3 或 Google App Engine BlobStore。问题是图片盗链。

关于谷歌存储，我用谷歌搜索了，我找不到防止图片盗链的方法。（不过我非常喜欢它的命令行工具 gsutil）
Amazon S3 具有“查询字符串身份验证”，可生成过期图像 URL。但这对SEO非常不利，不是吗？不断更改 URL 会产生非常负面的影响，因为将图像及其相关 URL 放入 Google 图片需要一年多的时间。我敢肯定，当 GoogleBot 过来打招呼时，更改此 URL 会立即产生负面影响。（更新：防止引用者在 Amazon S3 中进行图片盗链的更好方法是使用存储桶策略。详细信息：http://www.naveen.info/2011/03/25/amazon-s3-hotlink-prevention-with-bucket-policies/）
Google App Engine BlobStore？我必须手动通过 Web 界面上传图片，~~它也会生成不断变化的 url~~。（更新：由于我对 Blobstore 一无所知，所以我犯了一个错误。通过使用 Google App Engine BlobStore，您可以使用任何 url 来提供您想要的图像。）

我需要的是简单的引荐来源网址保护：仅当引荐来源网址是我的网站时才显示图片。

有没有更好的方法来防止图片盗链。由于云带宽成本极高，我不想申请破产。

更新：

~~这三个还是很难选择的，各有优劣。~~ BlobStore 似乎是最终的选择。

【问题讨论】：

我不确定，但如果您阻止盗链，如果您可以将您的图片放入 Google 图片搜索中，我会感到惊讶。
@sharth：好点。我刚刚搜索过，Googlebot 中没有引荐来源网址。只有一个代理：Googlebot-Image/1.0。
防止盗链成功了吗？干杯。

标签： google-app-engine amazon-s3 cloud-hosting hotlinking google-cloud-storage

【解决方案1】：

最简单的选择是使用 blobstore。您可以提供您想要的任何上传接口 - 由您自己编写 - 并且 blobstore 不限制您的下载 URL，仅限制您的上传 URL。只需设置适当的标头，您就可以在任何 URL 下提供 blobstore 图像，或者您可以使用 get_serving_url 来利用内置的快速图像服务支持，它会生成神秘但一致的 URL（但不会让您做引用检查）。

不过，我建议您考虑一下这是否是您面临的实际问题。按照今天的标准，一些热链接图像消耗的带宽非常少，而且这首先不是特别常见的做法。正如@sharth 在 cmets 中指出的那样，它也可能会影响 SEO，因为除了链接到托管它们的页面之外，图像搜索往往会在自己的窗口中显示图像。

【讨论】：

是否有任何命令行工具可以将图像上传到 blobstore？
@DocWiki 不，但是 blobstore API 可以通过 remote_api 使用，因此您可以相当简单地编写一个。
既然你在这里，我想了解一些关于 Blobstore 的信息。我知道应用引擎中每个请求有 30 秒的限制。当我将视频上传到应用引擎 Blobstore 时，此限制是否适用？ Blobstore 的最大单个文件大小为 2GB，如果我通过 HTML 表单上传，可能需要几个小时。每个请求 30 秒的限制是否适用？
@DocWiki 30 秒的执行时间限制仅适用于您的代码实际执行的时间——直到用户发送整个请求才开始，并在您发送响应后立即结束（在他们收到之前）。

【解决方案2】：

每当我重新开始为统计 Web 服务编码时，我都必须动态生成图像和图表。生成的图像将取决于请求参数、数据存储库的状态和一些标头信息。

因此，如果我是你，我会编写一个 REST Web 服务来提供图像。不太难。这也很棘手，因为如果您不喜欢某个特定的 IP 地址，您可以展示吐舌的卡通片（或 OBL 桑巴舞在被轰炸时跳舞的动画 gif），而不是数据请求的图像。

对于您的情况，您会在 http 标头中检查引荐来源网址（或引荐来源网址），对吗？我很怀疑，因为人们可以并且会隐藏、空白甚至伪造 http 标头中的引用字段。

因此，不仅要检查 referer 字段，还要创建一个值发生变化的数据字段。该值可以是简单的值匹配。

在世界大战期间，罗斯福和丘吉尔通过加密进行了交流。他们每个人都有一个相同的磁盘堆栈，其中包含加密机制。每次对话后，双方都会丢弃磁盘（并且从不重复使用），以便下次他们再次通话时，他们会伸手去拿堆栈中的下一个磁盘。

您的图像消费者和图像提供者将携带相同的 32 位令牌堆栈，而不是一堆磁盘。 32 位将为您提供约 40 亿个十分钟的周期。堆栈是随机排序的。众所周知，“随机生成器”并不是真正随机的，并且实际上算法的方式可以在提供足够长的序列时进行预测，因此您应该使用“真正的随机生成器”或每周对堆栈重新排序。

由于延迟问题，您的提供商将接受当前周期、上一周期和下一周期的令牌。其中期间 = 扇区。

浏览器上的 ajax 客户端（可能是 gwt）每十分钟会从服务器获取更新的令牌。 ajax 客户端将使用该令牌来请求图像。您的图像提供者服务会拒绝一个陈旧的令牌，而您的 ajax 客户端将不得不从服务器请求一个新的令牌。

这不是一种防火方法，但它是防碎的，因此它可以减少/阻止垃圾邮件请求的数量（我想几乎为零）。

我生成“真正随机”序列的方式又快又脏。我通过手动重新排序或删除序列值花费几分钟手动投入一些活动扳手，进一步研究算法生成的“随机”序列。这会破坏任何算法的可预测性。也许，你可以写一个活动扳手投掷器。但是算法猴子扳手投掷者只是在另一个可预测算法之上添加一个可预测算法，这根本不会降低整体可预测性。

您可以通过使用循环冗余匹配作为一种快速而肮脏的“加密”令牌匹配机制来进一步限制这种情况。

假设您有一个被分成 8 个等距扇区的圆圈。您将拥有一个 3 位二进制数，以便能够寻址所有 8 个扇区中的任何一个。想象一下，每个扇区进一步细分为 8 个子扇区，这样现在您将能够使用额外的 3 个字节来寻址每个子扇区，总共 6 个字节。

您计划每 10 分钟更改一次匹配值。您的图像提供者和所有已批准的消费者将拥有相同的扇区地址堆栈。每十分钟他们就会丢弃扇区地址并使用下一个。当消费者向您的提供者发送匹配值时，它不会发送扇区地址，而是发送子扇区地址。因此，只要您的提供商收到属于当前接受的扇区的子扇区地址，提供商服务就会以正确的图像进行响应。

但是子扇区地址是通过混淆排序算法重新映射的。这样同一扇区内的每个子扇区地址看起来根本不相似。这样一来，并非所有浏览器都会收到相同的令牌值或高度相似的令牌值。

假设您有 16 位扇区地址，每个扇区有 16 位子扇区地址，构成一个 32 位令牌。这意味着您有能力让 65536 个并发浏览器客户端携带相同的令牌扇区，但没有两个令牌具有相同的低可预测性值。这样您就可以为每个会话 ID 分配一个令牌子扇区值。除非您的图像提供程序服务有超过 65536 个并发会话，否则没有两个会话 ID 需要共享相同的子扇区令牌地址。这样，除非垃圾邮件发送者可以访问伪造会话 ID 的设备/设施，否则除了拒绝服务攻击外，您的图像提供者不会被发送垃圾邮件。

低可预测性意味着窥探者或窥视者编造可接受的令牌以向您的图像提供者服务发送垃圾邮件的可能性较低。

当然，普通的机器人无法获得成功 - 除非你真的冒犯了 ANNONYMOUS 小组并且他们决定向你的服务器发送垃圾邮件纯粹是为了好玩。即便如此，如果您将活动扳手扔到扇区地址堆栈和子扇区映射中，也很难预测下一个令牌。

顺便说一句，循环冗余匹配实际上是一种纠错技术，而不是加密技术。

【讨论】：

大声笑你在说什么？仅供参考，我的英语很烂
哇。 1）防盗链的重点是通过使其他用户无法使用来防止用户直接链接到您的资源。发送引用标题的用户不是您的对手，链接到您的图像的人是，他们无法控制其他用户的浏览器。 2）我很确定罗斯福和丘吉尔没有使用磁盘，因为它们是在第二次世界大战结束 30 年后才发明的。 3）你在说的是一次性垫，与手头的问题。 4）不要发明自己的加密货币。只是不要。
我注意到您说“光盘”时可能指的是黑胶唱片，这是准确的。不过，它仍然与 OP 的问题无关。
这是“不用担心热链接”的讽刺方式吗？

【解决方案3】：

极客文章的简单版本，在谷歌应用引擎中构建一个处理程序来获取和服务器图像。您可以修改标题以指定 png 或其他内容，但您正在从另一个位置返回图像。然后，您可以在处理程序中检查您的请求引荐来源信息，并在有人试图访问“热链接”图像时采取适当的措施。当然，因为您从不暴露实际图像，所以不可能进行热链接。 =)

【讨论】：

并在每次响应时从第三方服务获取并返回图像？当然，如果您喜欢高带宽账单，那就这样做吧。
我暗示了谷歌应用引擎 blobstore，因为据我所知，通过应用部署存储静态图像是我知道在那里存储图像的唯一方法。我想你有一个观点，我没有具体说 blobstore，因为这是他问题的一部分......
那你不是真的“从另一个位置返回图像”，是吗？这就是让我相信你在谈论从其他地方获取图像的原因。
我的意思是当图像的 url 是 blobstore url 时，您可以指定“examplewebsite.com/images/image1234.png”。对于中小型网站直接提供图片，Google 的带宽费用非常合理。 =)
嗯，blobstore 允许您在任何您想要的 URL 下提供图像 - 唯一的“blobstore URL”是上传 URL 和 get_serving_url。我同意 App Engine 的带宽费用是合理的 - 我更担心 OP 为每个请求支付三倍的费用。

【解决方案4】：

您应该知道 File API 仍处于试验阶段，请查看此问题：

http://code.google.com/p/googleappengine/issues/detail?id=6888#c20

我正在开发一家正在从 Blobstore 迁移到 Amazon S3 的初创公司

【讨论】：