You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AwsRequestSigning is broken for S3 object keys that contain special characters that need URL encoding (most notably whitespace and percent characters that are quite common in filenames).
This triggers a signature mismatch and 403 responses from AWS.
Repro steps:
Given a S3 object with object key test file (with space):
Request against envoy: GET /test%20file
Canonical request as returned in the AWS error response:
GET
/test%20file
host:bucket.s3.us-west-2.amazonaws.com
Canonical request as printed in the debug output from Envoy:
GET
/test%2520file
host:bucket.s3.us-west-2.amazonaws.com
@j-gottfried thank you for your bug report. I've confirmed that in the attached PR we now correctly avoid double encoding and added test cases to match.
AwsRequestSigning is broken for S3 object keys that contain special characters that need URL encoding (most notably whitespace and percent characters that are quite common in filenames).
This triggers a signature mismatch and 403 responses from AWS.
Repro steps:
Given a S3 object with object key
test file
(with space):Request against envoy:
GET /test%20file
Canonical request as returned in the AWS error response:
Canonical request as printed in the debug output from Envoy:
Issue:
the S3 object key is already UrlEncoded in the request, but the envoy AwsRequestSigning implementation is quoting it yet another time resulting in a double-quoting and a 403 response from AWS as a result, see
https://github.com/envoyproxy/envoy/blob/main/source/extensions/common/aws/utility.cc#L155-L208
The text was updated successfully, but these errors were encountered: