-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problems with auth when following redirects #1762
Comments
For custom redirect behavior, I would first look and see how much you can accomplish with the Note that if you are using Guzzle V5, the GuzzleHandler for V5 does have a whitelist for accepted options, which you'll need to add |
thanks. I will look into those pointers. in case it wasn't clear originally, I didn't intend this as merely a "request for guidance" type ticket. I am arguing that both cases are potentily bugs in the PHP SDK. i realise it may be somewhat undefined area but it makes sense to me that if a redirect is sent by the server (or a middleman proxy) that the PHP SDK should follow that redirect and regenerate the auth header appropriately which is what boto and the java SDKs do in the same scenario. |
Currently the redirect is handled completely by Guzzle before getting back to the SDK, and the behavior isn't currently customized. I don't think header removal on redirects is within the scope of the SDK - it assumes too much about the use case, and the user should have access to it with the callback option in |
I've marked this a feature-request for the next major version of the SDK (v4). As you point out, Guzzle removes the authorization header. Further, Guzzle's There is an entry point to re-sign requests using the current version of the SDK. A http_handler can be substituted for the default http handler. In providing a different http handler, you'd be able to modify the redirect behavior to enable re-signing redirects. |
Hi @gardenia, Just wanted to let you know that we're closing this issue, but will keep any closed issues with the |
This issue is now closed. Comments on closed issues are hard for our team to see. |
Hi,
I have written a proxy between the php and S3. One of the features of the proxy is to send redirects (status 307) back to the client so they can go direct and offload large payloads from the proxy. examples of which are,. GETs on large files or PUTs of multipart upload parts.
NOTE: for reasons I won't go into: I am using the "endpoint" feature to direct traffic to the proxy (rather than HTTP_PROXY). example:
The specific problem I'm having is that when the proxy returns a redirect (status 307) the client will misbehave in the following ways:
1] if the redirect is to a presigned URL then GuzzleHttp/RedirectMiddleware.php will retain the original request headers and try to resend them along with the presigned URL when following the redirect resulting in S3 complaining about extraneous request headers:
Error executing "GetObject" on "http://localhost:8081/redacted-01/hello.txt"; AWS HTTP error: Client error:
GET http://localhost:8081/redacted-01/hello.txt
resulted in a403 Forbidden
response:AccessDenied
There were headers present in the reques (truncated...)AccessDenied (client): There were headers present in the request which were not signed -
AccessDenied
There were headers present in the request which were not signedx-amz-dateD29503FF38483831k7QYPI0bjIf8iqOO0mgunxz9pYidg6IXZKbwqdtFNah3bqNT67cuDuptcOQFtjBSTAlDL2zeDPU=I was able to do a local workaround for this as follows:
2] if the redirect is to a plain URL, e.g. :
< HTTP/1.1 307 Temporary Redirect
< Location: https://s3.eu-west-1.amazonaws.com/redacted-01/hello.txt
< Content-Length: 0
then there the same fix as above is required to slurp out the extraneous headers but additionally then the request gets sent without an "Authorisation" header. I believe that what needs to happen in this case is that the S3Client needs to calculate a new "Authorisation" header but am not familiar enough with the codebase to know how to get it to do that after the RedirectMiddleware. I'd be happy to have a stab at it if someone can give me some pointers.
NOTE: both of these cases work fine in boto.
Case #1: works fine in boto but NOT the S3 java SDK
Case #2: works fine in boto and the S3 java SDK
The PHP SDK (v3) doesn't work with either case.
Any feedback / suggestions, in particular how to workaround case #2 are very welcome.
Thanks.
The text was updated successfully, but these errors were encountered: