Google app engine 谷歌存储或亚马逊S3或谷歌应用程序引擎BlobStore

我打算建立一个网站使用谷歌应用程序引擎。我的公共站点包含数千张图片。我想在云中存储这些图片：谷歌存储、亚马逊S3或谷歌应用程序引擎BlobStore。问题是图像热链接

至于谷歌存储，我在谷歌上搜索过，我找不到防止图像热链接的方法。（不过我非常喜欢它的命令行工具gsutil）

AmazonS3具有“查询字符串身份验证”，它生成过期的图像URL。但这对搜索引擎优化非常不利，不是吗？不断更改URL会产生相当负面的影响，因为需要一年以上的时间才能将一幅图像及其相关URL转换为Google图像。我敢肯定，当谷歌机器人过来打招呼时，更改这个URL会立即产生负面影响。（更新：推荐人在Amazon S3中预防图像热链接的更好方法是使用Bucket策略。详细信息如下：）

谷歌应用引擎BlobStore？我必须通过网络界面手动上传图片，它也会生成不断变化的URL。（更新：由于我对Blobstore一无所知，所以我犯了一个错误。通过使用Google App Engine Blobstore，你可以使用任何url来提供你想要的图像。）

我需要的是简单的推荐人保护：只显示图像时，推荐人是我的网站

有没有更好的方法来防止图像热链接。我不想因为云带宽的极高成本而申请破产

更新：

---

仍然很难从这三个选项中进行选择，它们各有利弊。BlobStore似乎是最终的选择。

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

因此，如果我是你，我会编写一个RESTWeb服务来服务这些图像。不太难。这也很棘手，因为如果你不喜欢某个特定的ip地址，你可以在数据请求中显示“舌头出了脸”的动画（或爆炸时OBL桑巴舞的动画gif），而不是图像

对于您的情况，您可以在http头上检查referer（或referer），对吗？我对此表示怀疑，因为人们可以而且将会隐藏、清空甚至伪造http头中的referer字段

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

二战期间，罗斯福和丘吉尔通过加密技术进行通信。他们每个人都有一个相同的磁盘堆栈，其中不知何故包含了加密机制。每次对话后，两人都会丢弃磁盘（并且永远不会重复使用），以便下次再次对话时，他们会接触堆栈上的下一张磁盘

您的映像使用者和映像提供者将携带相同的32位令牌堆栈，而不是磁盘堆栈。32位将提供约40亿个10分钟周期。堆栈是随机排序的。众所周知，“随机生成器”不是真正的随机生成器，实际上是算法，如果提供足够长的序列，则可以预测，因此您应该使用“真正的随机生成器”或每周对堆栈重新排序

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

浏览器上的ajax客户端（大概是gwt）每十分钟就会从服务器上获得一个更新的令牌。ajax客户端将使用该令牌请求图像。您的图像提供程序服务将拒绝过时的令牌，并且您的ajax客户端必须从服务器请求一个新的令牌

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

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

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

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

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

但子部门地址通过模糊排序算法重新映射。因此，同一部门内的每个子部门地址看起来根本不相似。这样，并非所有浏览器都会收到相同的令牌值或非常相似的令牌值

假设您有16位扇区地址，每个扇区有16位子扇区地址，组成一个32位令牌。这意味着你可以负担得起