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
AwsV4HttpSigner should have an option / signer property that prevents creation of "x-amz-content-sha256"-Header.
Use Case
I currently use software.amazon.awssdk.auth.signer.Aws4Signer to sign my requests to API Gateways. But since it's deprecated I wanted to switch to the proposed software.amazon.awssdk.http.auth.aws.signer.AwsV4HttpSigner.
Unfortunately the requests don't work anymore with the new signer, I always get a "403 Forbidden" response. After having a look at the generated headers I found out that the problem seems to be the "x-amz-content-sha256"-Header that is created by AwsV4HttpSigner (and used for the signature) but not by the deprecated Aws4Signer. Without the header the request works, with the header it doesn't.
I also tried to prevent the payload signing by using .putProperty(AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED, Boolean.FALSE) but this only results in a x-amz-content-sha256: UNSIGNED-PAYLOAD header that the API-Gateway also doesn't seem to like.
Proposed Solution
I don't know what to suggest.
I first thought of a new signer property, like CONTENT_HASHING_HEADER_ENABLED.
The problem with a new property could be that it could collide with the existing AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED (PAYLOAD_SIGNING_ENABLED=true, CONTENT_HASHING_HEADER_ENABLED=false)
After having a look at the signer classes I found out that the contentHash is a really essential part of the signing process. So actually I don't know how to circumvent the problems that occur when accessing the execute-api
Other Information
Maybe it's already possible to prevent the header. I didn't find a way and my request #5566 wasn't answered.
Acknowledgements
I may be able to implement this feature request
This feature might incur a breaking change
AWS Java SDK version used
2.27.20
JDK version used
openjdk version "22.0.2" 2024-07-16
Operating System and version
macOS 14.6.1 (23G93)
The text was updated successfully, but these errors were encountered:
I think the best way to avoid the problem would be for the API gateway to accept the x-amz-content-sha256 header. But I don't know where to make this suggestion.
Describe the feature
AwsV4HttpSigner should have an option / signer property that prevents creation of "x-amz-content-sha256"-Header.
Use Case
I currently use software.amazon.awssdk.auth.signer.Aws4Signer to sign my requests to API Gateways. But since it's deprecated I wanted to switch to the proposed software.amazon.awssdk.http.auth.aws.signer.AwsV4HttpSigner.
Unfortunately the requests don't work anymore with the new signer, I always get a "403 Forbidden" response. After having a look at the generated headers I found out that the problem seems to be the "x-amz-content-sha256"-Header that is created by AwsV4HttpSigner (and used for the signature) but not by the deprecated Aws4Signer. Without the header the request works, with the header it doesn't.
I also tried to prevent the payload signing by using .putProperty(AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED, Boolean.FALSE) but this only results in a x-amz-content-sha256: UNSIGNED-PAYLOAD header that the API-Gateway also doesn't seem to like.
Proposed Solution
I don't know what to suggest.
I first thought of a new signer property, like CONTENT_HASHING_HEADER_ENABLED.
The problem with a new property could be that it could collide with the existing AwsV4FamilyHttpSigner.PAYLOAD_SIGNING_ENABLED (PAYLOAD_SIGNING_ENABLED=true, CONTENT_HASHING_HEADER_ENABLED=false)
After having a look at the signer classes I found out that the contentHash is a really essential part of the signing process. So actually I don't know how to circumvent the problems that occur when accessing the execute-api
Other Information
Maybe it's already possible to prevent the header. I didn't find a way and my request #5566 wasn't answered.
Acknowledgements
AWS Java SDK version used
2.27.20
JDK version used
openjdk version "22.0.2" 2024-07-16
Operating System and version
macOS 14.6.1 (23G93)
The text was updated successfully, but these errors were encountered: