Skip to content
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

Feature/credential provider #5

Closed
wants to merge 10 commits into from
Closed

Conversation

jeskew
Copy link
Contributor

@jeskew jeskew commented Apr 18, 2017

Per the discussion at aws/aws-sdk-js#1483, the homedir locator will use the same logic as the AWS CLI rather than relying solely on os.homedir.

In line with offline discussion, I'm breaking this into a few separate PRs:

@jeskew jeskew requested a review from chrisradek April 18, 2017 01:36
@jeskew jeskew force-pushed the feature/credential-provider branch from 52d19b2 to aaa2480 Compare May 1, 2017 08:39
expect(isCredentials(await provider())).toBe(true);
});

it('should return the resolved value of the first successful promise', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So here's an interesting question. Should we move to the next Provider in the chain no matter what the error is (like we do today) or should we stop the chain if a Provider rejects due to bad config (like Python, e.g. Incorrect profile specified)?

I'm leaning towards the latter, since we've had some customers complain about the error messages our chain currently gives. Maybe this is a good first use for the cancellation token?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the way the chain is linked together with .catch handlers, error messages for anything other than the EC2 provider will just get swallowed and replaced with a less useful message.

Rather than a cancellation token, what if the providers always threw a CredentialsError with a tryNextLink boolean property? Bad config errors would set the property to false, unforeseen errors would return undefined, and the next handler in the chain would only be invoked if the property were true.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that sounds reasonable.

@jeskew jeskew force-pushed the feature/credential-provider branch from aaa2480 to 0a29eef Compare May 25, 2017 01:04
@jeskew jeskew force-pushed the feature/credential-provider branch from 0a29eef to 1f2bc3c Compare May 25, 2017 01:26
@jeskew
Copy link
Contributor Author

jeskew commented Jun 30, 2017

Fully implemented via #23, #24, #25, #26, and #30

@jeskew jeskew closed this Jun 30, 2017
@jeskew jeskew deleted the feature/credential-provider branch June 30, 2017 22:52
@lock
Copy link

lock bot commented Sep 26, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.

@lock lock bot locked as resolved and limited conversation to collaborators Sep 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants