我正在使用 AWS Federated Web Identitiy Playground我想知道如何使用签名 V4 来访问 AWS 或特别是 S3。
如果我查看 Sig4.js文件正在加载，它
/**
* Contains functions to construct a canonical request, create the string to sign,
* calcuate the signature, and finally to make a signed sigv4 request. Also contains
* a function to make REST calls to S3.
*/
我不确定允许对 S3 进行 REST 调用的方法(提供方法 callS3WithREST)。尽管该方法包含在 sig4 中，但它没有使用其任何逻辑。
在阅读 AWS 文档时，他们强调对 AWS 服务的所有请求始终使用签名 V4。所以我想知道:
问题:
我不应该使用签名对 S3 进行 REST 调用吗？那么签名过程的目的是什么？感谢您的一些澄清。
最佳答案
您绝对需要将 REST 请求签名到 S3，否则除非请求涉及匿名用户可用的内容，否则它们不会成功。而且，是的，您“应该”使用签名版本 4 与 S3 交互，因为(除其他原因外)较新的 S3 区域不支持较旧的签名版本 2。
令人好奇的是，callS3WithREST 似乎实际上是 Signature Version 2 的实现。
我根本不清楚为什么会出现这种情况，但我有一个令人信服的理论:它是旧代码复制/粘贴和/或从 V2 脚本中遗留下来的，而 V2 脚本是该脚本的前身。
S3 的签名版本 2 实现几乎与其他 AWS 服务支持的 V2 完全相同...但差异足以导致不兼容。
(S3 的 V2“要签名的字符串”与标准实现不同，不包括作为第二行的 Host: header 值，大概是因为“规范资源”中需要存储桶名称"部分使其变得重复，并且同一存储桶通常有多个变体主机名)。
因此，由于算法的差异，V2 签名库必须为 S3 破例。
对于 V4 来说情况并非如此，V4 足够全面，如果不做出任何不当假设，相同的代码可以签署 S3 以及其他服务的请求。
因此，我怀疑这最好的解释是，在上一世，这是一个 Signature V2 脚本被转换为 V4 脚本时留下的一些不恰当的代码。
关于javascript - 为什么使用 AWS Signature v4 对 S3 进行 REST 调用并未真正使用签名过程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29457974/