我想知道如何在我的网站上保护图片的安全。我们有一个需要登录的网站，然后用户可以在数据库中查看数以千计的不同图像，这些图像都以其 ID 命名。
即使您需要登录才能以正确的方式查看图像...没有什么可以阻止用户通过键入 <website-director>/image-folder/11232.jpg 或其他内容来浏览图像。
这不是世界末日，但绝对不理想。我看到要阻止这个 facebook，只需将图像命名为更复杂的名称 + 将它们存储在散列文件夹中。
Gmail 做了一件很有趣的事情，他们的图片标签是这样的：
<img src=/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5>
我认为 src 属性必须包含对图像的引用？？...gmail 是如何解决这个问题的？
目前这更多是出于教育目的，因为我认为这个 gmail 方案对于我们的实施来说可能是矫枉过正。
提前感谢您的反馈， 安德鲁
【问题讨论】：
我认为 src 属性必须包含对图像的引用？
GMail 正在引用图像。它只是被动态拉取，可能基于 th=12d7d49120a940e5 字符串。
尝试浏览到http://mail.google.com/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
它不是直接指向其在服务器文件系统上的位置，而是使用动态脚本（图像甚至可能在数据库中，谁知道呢）。
【讨论】：
除了从您的 web 应用程序动态提供图像外，还可以使用 web 应用程序动态授权访问网络服务器将提供的静态资源——通常是将文件放在网络服务器的某个位置可以访问但未映射到任何公共 URI，然后使用 X-Sendfile（lighttpd，Apache 与 mod_sendfile，其他），X-Accel-Redirect（nginx），X-Reproxy-File（Perlbal）等。 FastCGI 您可以将应用程序配置为 FastCGI“授权者”角色而不是内容提供者。
任何这些都可以让您检查被授权的图像和用户的会话，并做出您需要的任何决定，而不会在图像发送到客户端的整个过程中占用后端应用程序的进程.这不是普遍正确的，但通常与后端应用程序的连接比与网络服务器的连接表示保留更多的资源，因此尽快释放它们是明智的。
【讨论】：
发出此 GET 请求后运行的代码：
/mail/?attid=0.1&disp=emb&view=att&th=12d7d49120a940e5
向浏览器输出图像。某些东西不必以.jpg 或.png 或任何结尾被浏览器视为图像的名称命名。这就是验证码算法能够根据 id 中的值提供不同图像的方式。比如这个链接：
提供这张图片：
所以答案实际上就是像 Facebook 那样混淆你的图片名称/链接，这样人们就不能轻易猜到它们。
【讨论】：