【问题标题】:Amazon S3 pre signed URLs using Amazon Java SDK and extra / characters使用 Amazon Java SDK 和额外 / 字符的 Amazon S3 预签名 URL
【发布时间】:2012-03-04 02:46:22
【问题描述】:

我一直在创建 Presigned HTTP PUT URL,一切都很好,直到我想开始在 S3 中使用“文件夹”;我希望键具有字符“/”。

现在,当我发送 HTTP PUT 请求时,我得到 Signature doesn't match,因为“/”可能更改为 %2F...如果我在创建预签名 URL 之前转义字符,效果很好,但是亚马逊控制台管理不理解它并将其显示为一个文件而不是子文件夹。

有什么想法吗?

附言
HTTP PUT 请求是使用带有 POCO NET 库的 C++ 发送的。

编辑
我正在使用从 C++ 到我的 Java Web 服务器的 Poco HttpRequest 来生成签名的 url(在响应中返回)。
然后,C++ 使用此 url 再次使用 Poco 将文件放入 s3。
问题是从 Web 服务器返回的 url 是通过 Poco URI 对象解析的,这些对象自动解码了 s3 对象密钥,从而改变了它。
考虑到这一点,我能够解决我的问题。

【问题讨论】:

  • 大概你的意思是来自POCO C++ libraries的 Network 库(即 Poco::Net 命名空间)?
  • 这可能是您的代码或您正在使用的库中的错误,因为我使用 ruby​​ 和 AWS-SDK ruby​​ 包构建了 URL 和表单,因此我将预签名的 https 放入“文件夹”S3。
  • @Chook:实际上是使用哪个通道将AWS Java SDK生成的预签名URL依次传递给C++(背景见my answer最后一段)?

标签: amazon-s3 urlencode


【解决方案1】:

棘手 - 我将尝试自下而上处理。

免责声明:我在视觉上检查 Poco 库而不是实际调试代码示例,这应该会更快地产生更可靠的结果,见下文;)

分析

如果我在创建预签名 URL 之前转义字符,它可以工作 很好,但是亚马逊控制台管理不理解它 并将其显示为一个文件而不是子文件夹。

后者源于 S3 实际上在存储级别上没有文件夹的概念,参见例如Index Document Support 中的索引文档和文件夹部分:

存储在 Amazon S3 中的对象存储在平面容器中,即 一个 Amazon S3 存储桶,它不提供任何分层 组织,类似于文件系统的。但是,您可以创建一个 使用对象键名的逻辑层次结构并使用这些名称来推断 包含这些对象的逻辑文件夹。

这正是AWS Management Console 在这里所做的:

AWS 管理控制台还支持文件夹的概念,通过 使用与前面示例中相同的键命名约定。

但是,您对 / 被编码为 %2F 的假设的测试证明,这确实是 Poco::Net 在以下情况下对 URL 进行编码的方式执行 HTTP PUT 请求。

潜在解决方案

为了让您的方案按预期工作,您需要弄清楚 URL 以这种方式编码的位置 - 我原则上可以想到两个组件:

Poco::Net

找出为什么 Poco::Net 编码的 URL 与 S3 不同(如果有的话,见下文)最好通过调试代码来完成,这就是我要开始的地方:

HTTPRequest 类依次使用URI 类,自动对传递给它的所有 URI 和 URI 部分执行一些规范化,特别是百分比编码的字符被解码。反过来,由方法encode() 处理,事情变得有趣并需要断点,请参阅URI.cpp:

  • 行 575 及以下。 - 这里 encode() 发挥了它的魔力,这似乎确实到位,只要函数内的代码和通过 reserved 参数传入的各种字符都不包含冒犯/(请参阅第 47 行 ff. 了解所使用的各个常量)
  • 因此,您可能希望在此函数中设置断点并回溯调用堆栈以找出哪些代码实际上正在预先进行编码,这可能根本不会产生违规行为,请参见下文。

Java => C++ 转换

您尚未指定,实际使用哪个通道将 AWS Java 开发工具包生成的预签名 URL 依次传递给 C++。鉴于 Poco::Net 功能的代码审查(请注意,仅目视检查,我自己还没有调试过)得出的结论是,在库本身中无法识别出明显的违规者,因此它似乎更有可能已经进入您的 C++ 层编码(当然可以通过调试轻松验证) - 例如,您是否偶然在这些组件之间使用了任何类型的 Web 服务?

祝你好运!

【讨论】:

  • 嗨,Steffen,感谢您的回答。 URI 构造函数确实是他的自动解码“制造问题”的人。我将编辑问题以供将来参考。
  • 很高兴您发现了问题 - 并感谢您依次跟进您的解决方案 (+1)!
猜你喜欢
  • 2018-12-27
  • 2012-03-24
  • 2021-10-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-03-20
  • 1970-01-01
  • 2021-12-26
相关资源
最近更新 更多