Explicitly remove X-Amz-Security-Token on 3xx redirect

[hunshcn]

Acknowledgements

• I have searched (https://github.com/aws/aws-sdk/issues?q=is%3Aissue) for past instances of this issue
• I have verified all of my SDK modules are up-to-date (you can perform a bulk update with go get -u github.com/aws/aws-sdk-go-v2/...)

Describe the bug

Happend on handle 307 response.

Like Authorzation, if the host has been changed, the X-Amz-Security-Token should also be remove from request.

Regression Issue

• Select this option if this issue appears to be a regression.

Expected Behavior

do not send X-Amz-Security-Token after 307 to a different host

Current Behavior

Now aws-sdk-go-v2 handle 307 response through http stdlib. It will remove the Authorzation header if host changed but X-Amz-Security-Token not.

Reproduction Steps

Possible Solution

No response

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

latest

Compiler and Version used

1.25.5

Operating System and version

Linux

[lucix-aws]

Can you add more details about the problems this is causing for you in an application / end user context? Ultimately I think it's a simple fix on CheckRedirect but I'd like to understand more about where you're hitting this and how it impacts you before acting on it.

[hunshcn]

Can you add more details about the problems this is causing for you in an application / end user context? Ultimately I think it's a simple fix on CheckRedirect but I'd like to understand more about where you're hitting this and how it impacts you before acting on it.

I use many different object storage vendors. For the unification of access, I built an s3-gateway, which proxy metadata request and return 307 to a backing s3 presigned url for get request.

When I use aksk to access s3-gateway, everything is fine, but I will encounter this problem if I use sessiontoken. Like the description in this issue, X-Amz-Security-Token will be forwarded by mistask.

[lucix-aws]

What is the end result of that workflow, though? Does the request fail, or is it simply a matter of concern that part of the signature for the original request is being forwarded?

Generally speaking issues are going to be prioritized relative to their impact. As the SDK is only really designed to work with official AWS services, I can't necessarily guarantee that the HTTP client will behave in an appropriate manner for your multi-backend setup.

I am okay with leaving this open as a feature request, since I do think it makes sense in principle to also remove the security token header if the client is also removing the main signature. For the time being you should be able to implement your own custom CheckRedirect behavior as a workaround.