-
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
Default credential provider failing to resolve #1125
Comments
@acinader Taking a look, working on the fix. |
@acinader A fix has been merged into master, could you try it to see if that fixes the issue? SDK cannot change the resolving order in the default credential provider because it's unified across all SDKs. |
I have updated to use the master branch but this hasn't made any changes, I am still getting the same error as before. |
@ArthurGuy Hmm, interesting, could you provide you php version, OS information then I could see if I could reproduce it there? Also may I ask which version of SDK start causing this break for you? Edited, to clarify the problem, are you suggesting that with current chain, using assume role always fails? (InstanceCredentialProvider cannot be resolved)? |
The sdk went from We are running on Ubuntu 16.04 LTS and php 7.0.8. The library is being pulled in as part of the laravel framework but for the previous test I did explicitly pull in the master branch of the sdk. |
@ArthurGuy So for sdk went from 3.19.28 to 3.19.31, there is no changes happen in Credentials. I'll take a look at Guzzle to see if something happen there. Thanks for the information, I'll see if I could reproduce. Just a quick workaround, if you are using instanceCredentials only, you could try use instanceProfile directly. |
I have placed user credentials onto the server which has gotten around this, if a solution isn't readily available I will switch to the |
@ArthurGuy I looked at guzzle, I don't think there is any related changes neither. I couldn't reproduce this issue locally. Could you provide more information? Is using |
I have tried a few combinations and its definitly the |
@ArthurGuy Interesting, thank you for your patience on this and appreciated that, could you open an issue in guzzle repo as well? I'll try again with guzzle 1.3.0 to see If I could reproduce |
@cjyclaire I've encountered an issue with this as well. We've tried running master with Guzzle 1.3.0 but still get the same error raised above. I broke apart the defaultProvider() and there seems to be an issue with chaining and memoizing together: $provider = Aws\Credentials\CredentialProvider::defaultProvider();
call_user_func( $provider )->wait(); // fails with "The promise was rejected with reason: Invoking the wait callback did not resolve the promise"
$env_creds = Aws\Credentials\CredentialProvider::env();
call_user_func( $env_creds )->wait(); // fails with "Could not find environment variable credentials in AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY"
$ini_creds = Aws\Credentials\CredentialProvider::ini();
call_user_func( $ini_creds )->wait(); // fails with "Cannot read credentials from /.aws/credentials"
$ecs_creds = Aws\Credentials\CredentialProvider::ecsCredentials();
call_user_func( $ecs_creds )->wait(); // fails with "Error retrieving credential from ECS (cURL error 28: Connection timed out after 1001 milliseconds..."
$instance_creds = Aws\Credentials\CredentialProvider::instanceProfile();
call_user_func( $instance_creds )->wait(); // returns valid credentials
$chain = Aws\Credentials\CredentialProvider::chain( $env_creds, $ini_creds, $ecs_creds, $instance_creds );
call_user_func( $chain )->wait(); // returns valid credentials
$simple_memo = Aws\Credentials\CredentialProvider::memoize( $instance_creds );
call_user_func( $simple_memo )->wait(); // returns valid credentials
$chain_memo = Aws\Credentials\CredentialProvider::memoize( $chain );
call_user_func( $chain_memo )->wait(); // fails with "The promise was rejected with reason: Invoking the wait callback did not resolve the promise" |
@ArthurGuy Interestingly, I still couldn't reproduce the issue with a fresh launched ec2 instance:
My dependencies (via composer) aws/aws-sdk-php 3.19.33 AWS SDK for PHP - Use Amazon Web Services in your PHP...
guzzlehttp/guzzle 6.2.2 Guzzle is a PHP HTTP client library
guzzlehttp/promises 1.3.0 Guzzle promises library
guzzlehttp/psr7 1.3.1 PSR-7 message implementation
mtdowling/jmespath.php 2.3.0 Declaratively specify how to extract elements from a ...
psr/http-message 1.0.1 Common interface for HTTP messages My php version
@dittto Thanks for the info., may I ask are you also finding this failing since |
@cjyclaire we're running the following:
The dependencies are the same version numbers as those you've listed, apart from my test was using aws-sdk-php on master. The PHP version is:
If I get some time free then I may try creating a little project with just this bug in it, as currently it's part of a giant Wordpress-based project. |
@cjyclaire stupid question but you were trying to get credentials from a role and there was nothing else in place to take precedence? |
@ArthurGuy Yeah, it is using the instance metadata credentials, also since it's a newly launch instance with an assume role, I didn't do any customization either. What I did is require straight forward. I launched a new ec2 instance with assume role that enabled with s3 access. I installed PHP 7 and SDK with all dependencies with composer. And I'm able to perform S3 operations with successful response. Also, given some time, tracking trace, the metadata credential is cached and correctly fetched. |
Hi, I'm getting this issue when creating a pre-signed URL with
I'm using |
@ArthurGuy @llernestal I'm having the same issue with |
Thanks for the following inputs, I'll take a second look at |
@cjyclaire I use the SDK directly, no Loaded PHP modules
|
We've had this issue as well! It still worked on version 3.19.21, but somewhere after that all our new servers crashed. As of today we still have this issue when we use the CredentialProvider::defaultProvider() |
@Nizari Quick question, does this start since guzzle version upgraded to 1.3.0 ? |
Hmmm, can't say for sure. What guzzle requirements does version 3.19.21 have in composer? If it's below 1.3.0, this could be related |
I specifically downgraded from guzzlehttp/promises 1.3.0 to 1.2.0 with AWS SDK 3.19.30 and the issue was no longer present. |
I was able to reproduce the issue: https://github.com/reproduce/guzzle/tree/issue1668 After a quick look in the code: the way how coroutines are handled has been changed in 1.3.0, which might be the guilty one. |
Is anyone on this gullze issue? |
It looks like it's nearly been solved. |
Hi guys! We are waiting for a final review before merging and tagging 1.3.1 with a fix. I will keep you posted. |
https://github.com/guzzle/promises/releases/tag/v1.3.1 is out containing a fix (confirmed in the reproduction environment) |
Closing, thank you all for the efforts in this, appreciate that. |
Upgraded to guzzlehttp/promises 1.3.1 but still facing this issue when using createPresignedRequest() with iam roles (default provider chain). Please help PHP Fatal error: Uncaught GuzzleHttp\Promise\RejectionException: The promise was rejected with reason: Invoking the wait callback did not resolve the promise |
please ignore.. I have solved the issue. |
I am using the
defaultProvider
to sign an elastic search request but a recent update to the SDK or guzzle has caused it to to start failing.I have isolated the problem to the chaining going on in the default provider, it seems that if the last item in the chain fails the whole request fails with the following error.
I am using the role based credentials (
instanceProfile
) but if that option appears last as it does with the default provider the request fails, if I reverse the last two options the promise resolvesThis Fails
This returns a credentials object
Has anyone encountered this or knows why it's happening?
The text was updated successfully, but these errors were encountered: