向 Amazon CloudFront 发布失效请求时 CallerReference 有何用途？
Amazon CloudFront 文档 没有提及“CallerReference”的用途或我的用途应该填写它，我在其他网站上看到的示例使用 guid 或当前日期。
AWS SDK for .NET 工具提示说它是为了防止重放攻击，但这就是日期标头的用途。
The Amazon CloudFront documentation doesn't mention what the "CallerReference" is for or what I should fill it with, the examples I have seen on other sites use a guid or the current date.
The AWS SDK for .NET tooltip says it's to prevent replay attacks, but that's what the date header is for.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Amazon CloudFront 文档（同时？！）指出CallerReference 是确保请求无法重播的唯一名称，请参阅InvalidationBatch 复杂类型了解详细信息：
对象失效中的调用者参考部分也证实了这一点，并提供了如何在实践中处理它的提示：
尽管示例也使用时间戳，但处理重放攻击的专用值据称比依赖日期标头提供了更大的灵活性，因此可能提高安全性（如果需要的话）。
The Amazon CloudFront Documentation (meanwhile?!) states that CallerReference is A unique name that ensures the request can't be replayed indeed, see InvalidationBatch Complex Type for details:
Section Caller Reference within Object Invalidation confirms this as well and provides a hint how to handle it in practice:
Despite the sample using a time stamp as well, a dedicated value to handle replay attacks supposedly provides more flexibility and thus potentially increased security (if so desired) than relying on a date header.
我的 2 美分给在未来读到这篇文章的人：
CallerReference 对于复杂且自动化的基于云的设置也很有用。想象一下部署设置，其中来自不同主机的许多脚本独立运行以验证和创建 CloudFront 分发。在这种情况下，您只希望一个创建请求成功。您可以使用固定的 CallerReference 来确保不会意外创建重复的分配。
my 2 cents for someone reading this in futuer:
CallerReference is also useful with complex and automated cloud based setup. Think of a deployment setup with many scripts from different hosts are running independently to verifying and creating CloudFront distribution. In such case you want only one create request to be successful. You can use fixed CallerReference to make sure you don't create duplicate distribution accidentally.