每当我回到为统计 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 伪造设备/设施，否则除了拒绝服务攻击外，您的图像提供者不可能被发送垃圾邮件。
低可预测性意味着窥探者或窥视者编造可接受的令牌以向您的图像提供者服务发送垃圾邮件的可能性较低。
当然，普通的机器人无法获得成功——除非你真的冒犯了匿名组并且他们决定向你的服务器发送垃圾邮件纯粹是为了好玩。即使那样，如果您将活动扳手扔进扇区地址堆栈和子扇区映射，也很难预测下一个令牌。
顺便说一句，循环冗余匹配实际上是一种纠错技术，而不是加密技术。