What is the bug?
The AWS SigV4 signature can get corrupted.
When using the SigningClientDecorator, the AWS signature is calculated before the sendRequest method, which seems to be a bit early for some clients.
Guzzle, for example, have middlewares and handlers that can potentially add new headers, these middlewares are executed inside the sendRequest method, which is called after signing the request by the SigningClientDecorator, which will lead to a signature mismatch.
How can one reproduce the bug?
- Use the
GuzzleClientFactory to create a client
- In the
options, have a middleware that adds a new header to the request
- Run
$client->info() or any other command
- You should see an error stating that there was a signature mismatch
# The private data in the error have been redacted
The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
The Canonical String for this request should have been
'GET
/
host:aws-host.aos.us-east-1.on.aws
new-header:<header-value>
x-amz-content-sha256:<hash>
x-amz-date:<date>
x-amz-security-token:<token>
host;new-header;x-amz-content-sha256;x-amz-date;x-amz-security-token
<hash>'
The String-to-Sign should have been
'AWS4-HMAC-SHA256
20251119T154521Z
20251119/us-east-1/es/aws4_request
39d0b2f58483c7d31e0b1ae5b11c831201821d2ac51f7c2850aae1f32e0bd590'
What is the expected behavior?
The AWS signature should include the newly added header in the calculation
What is your host/environment?
ECS on AWS, using the php:8.3-fpm base image
Do you have any screenshots?
Do you have any additional context?
This also happen when having the open-telemetry package installed and enabled, since they also inject some w3c tracing headers just before sending the request. This is how we discovered the issue, we first thought it was due to open-telemetry but after debugging and narrowing it down, we figured out it was due to the wrapping of the http client inside an aws signing decorator.
What is the bug?
The AWS SigV4 signature can get corrupted.
When using the
SigningClientDecorator, the AWS signature is calculated before thesendRequestmethod, which seems to be a bit early for some clients.Guzzle, for example, have middlewares and handlers that can potentially add new headers, these middlewares are executed inside the
sendRequestmethod, which is called after signing the request by theSigningClientDecorator, which will lead to a signature mismatch.How can one reproduce the bug?
GuzzleClientFactoryto create a clientoptions, have amiddlewarethat adds a new header to the request$client->info()or any other commandWhat is the expected behavior?
The AWS signature should include the newly added header in the calculation
What is your host/environment?
ECS on AWS, using the
php:8.3-fpmbase imageDo you have any screenshots?
Do you have any additional context?
This also happen when having the
open-telemetrypackage installed and enabled, since they also inject some w3c tracing headers just before sending the request. This is how we discovered the issue, we first thought it was due to open-telemetry but after debugging and narrowing it down, we figured out it was due to the wrapping of the http client inside an aws signing decorator.