Closed mildm8nnered closed 2 years ago
processURL
isn't actually used by SotoCore service operations. It is there just to provide support for signing URLs. That is why this hasn't been caught earlier. If you want to add a PR for this that would be most helpful.
Describe the bug
So I think there's an issue with the implementation of
processURL
inAWSSigner
. Consider a request to begin a multipart upload, with bucket "MyBucket", the path according to Amazon should be "MyBucket?uploads".But for signing, Amazon considers the encoded query string to be
uploads=
, and the=
is important. Amazon will fail signatures that do not use that form as the second line of the canonical request string constructed during signing.The issue is that
AWSSigner.processURL()
does not add the=
in this case. At or around line 65, I thinkreally wants to be
Assuming I'm right, it's really surprising to me that this hasn't come up before. I grabbed
soto-s3-file-transfer
, but looking there, the begin multipart request gets passed through another very similar piece of code, in AWSRequest.swift (around line 285), that performs an almost identical operation, but taking care of nil values correctly:To Reproduce
Steps to reproduce the behavior:
Just pass a URL with path
MyBucket?uploads
to AWSSigner.processURL() to see that it does not add the=
Expected behavior
processed URLs should be in the correct format for Amazon canonical request string
Setup (please complete the following information):
Additional context Add any other context about the problem here.