【发布时间】：2018-07-25 15:01:37
【问题描述】：
我计划将 CloudFront 用作我的站点的服务器缓存，由单点 URL 保护。使用签名 URL 的原因是只允许经过身份验证的用户访问内容。
但是，我的 webapp 还需要在客户端使用缓存。现在，由于签名的 URL 只会在短时间内有效，然后会生成一个新的 URL，这将破坏客户端的缓存。虽然客户端会收到相同的资源，但它会有一个新的签名 URL，客户端浏览器将无法从缓存中获取它。
我想对长期存在的资源使用有效期短的签名 URL 的原因之一是可以控制传输的数据。在最好的情况下，这些资源被缓存在客户端。如果没有，它们将缓存在 CloudFront 上，CF 将交付它们并节省我的 Web 应用程序服务器的资源。但是我想防止攻击者从 CF 大量下载资源并给我带来额外的成本。
有没有一种方法可以使用签名 URL 以外的其他方式来保护对 CloudFront 资源的访问？例如，一个好东西是签名的 cookie。客户端会在 webapp URL 上请求资源，webapp 将返回重定向到该资源的长期 CF URL，但检索资源只能使用具有短期有效期的签名 cookie。客户端仍会看到长 URL 并可以缓存资源，但资源只能在短时间内用于下载。 我不想乱用 IP 地址，因为它们不可靠，通常一个 IP 后面可能有很多用户等。
有没有类似的东西可以克服签名 URL 的本地缓存限制？
【问题讨论】：
-
你能控制客户端的缓存行为吗？您可以让它在存储/访问缓存时忽略 URL 的签名部分，以便它可以在本地缓存。 （这假设请求的内容在后续调用中不会改变。）
-
感谢您的想法，但我不能。无论如何，签名的 cookie 对我来说是正确的答案，出于某种神秘的原因，我在询问之前无法自己谷歌搜索。
-
值得注意的是，对于给定的文件和过期日期作为输入，签名的 URL 函数将始终返回相同的 URL，因此文件将被缓存。因此，您可能希望使用绝对过期日期而不是通常的 time() + X 秒。
-
我明白了。但是时间 + X 秒正是我想要的。我想让 URL 只在几秒钟内有效，这样攻击者就不会多次下载文件，因此他可能会通过 CF 给我带来巨大的损失。
标签： amazon-web-services cloud amazon-cloudfront http-caching pre-signed-url