Is it possible to replace the default V4 signer with a custom signer?

[alberto-miranda]

Issue #228 seems to suggest that it should be possible, but I found no documentation on the topic. The Customizing the AWS SDK for Go V2 Client Requests docs also seem to suggest that this should be possible by providing a custom FinalizeMiddleware, but offer no guidance on how to replace the default one. Is there any supported way to do this within the current SDK?

[cajund]

Hi Folks,

Want to chime in here with an example of a possible use case:

For client security reasons, we need to make API calls through a proxy as the client's network can only communicate over white listed IP addresses, so all API calls need to pass through a proxy (nginx, in this case). As part of this operation, the host header is rewritten.

However, as the host header is required when generating the V4 signature, this causes the signature check to fail on the receiving end. One of the potential workarounds is to sign the request using the S3 endpoint in the host field, and not the proxy endpoint url. Seems that a custom signer would resolve the issue.

@alberto-miranda - these are great resources that you have found. Any progress on finding more guidance?

Thanks.

[lucix-aws]

If you're just trying to modify the signing behavior in place you don't have to touch the middleware. Options for services that use sigv4 (so basically all of them) have an HTTPSignerV4 field that you can set (example).

The authentication resolution workflow and signing can be heavily modified (again, without having to deal with middleware), see https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/auth/. For what you're describing though modification of that field on options should suffice.

[cajund]

Yes, there are some significant challenges to using the middleware. I am effectively adding three lines of code, but getting them into the system is not as easy. While I was able to add a middleware, there were dependent elements that are used that are private, and unaccessible to my code (such as the internal resolvedAuthScheme mechanism).

I'll work on replacing the signer, seem a little smoother of a road.

Thanks for your reply.

[cajund]

@lucix-aws Perhaps you can comment on this once more. I think I have the signature issue worked out as I am no longer getting the Signature Mismatch error. However, I am getting different unexpected errors that were not happening using the provided SDK code and the direct URL to the service.

For example, after spending the day constructing my own signing method to allow the traffic through the nginx proxy, I received this error:

operation error S3: PutObject, https response error StatusCode: 400, RequestID: 5PWJ55C9A17TTD7Q, HostID: eseKx2e6EHx24vzyyNfmc13rnSlrhsZqYHjDVKX5ZSURC2Eo4aQDqLNEJArMiP33vhkIE8Ln55k=, api error InvalidArgument: x-amz-server-side-encryption header is not supported for this operation.

Removing this from my code, and rerunning, I get this (payload is 6 Mb):

operation error S3: PutObject, https response error StatusCode: 400, RequestID: 7SYQWM0NVYGK9Z4G, HostID: nvuTA2AaQot1PXMsqyygZ9f80y7ZqClQKp41KRFJShlmr6SKdproGYRV6u6IBYmJutRUhQW+km8=, api error MaxMessageLengthExceeded: Your request was too big.

Finally, triggering the Multipart code, setting the part to 5 Mb, which triggers a different code route:

operation error S3: CreateMultipartUpload, https response error StatusCode: 404, RequestID: N64RQXBC1T7NGVT1, HostID: jN4eb/KCk0u4nDxJWcpWcIcJIZv/D2Zkeqeo0ZV1IqnUmiH+dky6/lsrh7p0EzzTDXcROmr7IhM=, api error NoSuchBucket: The specified bucket does not exist

As you can imagine, this is all likely related to the signing activity, as nothing has changed aside from that. I'm sure you can also imagine how frustrating all of this has been.

Thanks for your help.