Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sigv2: Do not encode canonical sub-resource value #636

Merged
merged 1 commit into from
Apr 1, 2017

Conversation

vadmeste
Copy link
Member

@vadmeste vadmeste commented Apr 1, 2017

Do not encode sub-resource value (such is uploadID) when building
canonicalized request string.

Do not encode sub-resource value (such is uploadID) when building
canonicalized request string.
@@ -316,7 +316,7 @@ func writeCanonicalizedResource(buf *bytes.Buffer, req http.Request, isPreSign b
// Request parameters
if len(vv[0]) > 0 {
buf.WriteByte('=')
buf.WriteString(strings.Replace(url.QueryEscape(vv[0]), "+", "%20", -1))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vadmeste can we test this with ListObjects() with some UTF-8 files and see how it works.

Copy link
Member Author

@vadmeste vadmeste Apr 1, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vadmeste can we test this with ListObjects() with some UTF-8 files and see how it works.

  • I already tested that case with more than 1000 objects which has unicode characters, and that to trigger 'next token' query params in web requests
  • I also tested v2 tests function of minio-go with AWS S3
  • I also tested manually many use cases

Besides, the change line affects only values of Resource parameters:

260 var resourceList = []string{
261     "acl",
262     "delete",
263     "location",
264     "logging",
265     "notification",
266     "partNumber",
267     "policy",
268     "requestPayment",
269     "torrent",
270     "uploadId",
271     "uploads",
272     "versionId",
273     "versioning",
274     "versions",
275     "website",
276 }

By the way, S3 spec is not clear about the behavior of this case.

How did I find the bug?

I made a manual change in minio-go to send uploadID="QsbxgdvySmWkYZ2X84hQPg==" instead of the one that it receives from AWS in list multipart uploads. In that case, AWS returns signature mismatch.

@harshavardhana harshavardhana merged commit ef0dc7e into minio:master Apr 1, 2017
@harshavardhana harshavardhana changed the title [need-review] sigv2: Do not encode canonical sub-resource value sigv2: Do not encode canonical sub-resource value Apr 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants