Skip to content

Support env var credential expiry#1187

Merged
JordonPhillips merged 1 commit intoboto:developfrom
JordonPhillips:refresh-env
May 5, 2017
Merged

Support env var credential expiry#1187
JordonPhillips merged 1 commit intoboto:developfrom
JordonPhillips:refresh-env

Conversation

@JordonPhillips
Copy link
Copy Markdown
Contributor

This adds support for environment credential expiration via the AWS_CREDENTIAL_EXPIRATION environment variable.

@JordonPhillips JordonPhillips added the pr/needs-review This PR needs a review from a member of the team. label May 1, 2017
@codecov-io
Copy link
Copy Markdown

codecov-io commented May 1, 2017

Codecov Report

Merging #1187 into develop will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #1187      +/-   ##
===========================================
+ Coverage       98%   98.05%   +0.04%     
===========================================
  Files           45       45              
  Lines         7277     7306      +29     
===========================================
+ Hits          7132     7164      +32     
+ Misses         145      142       -3
Impacted Files Coverage Δ
botocore/credentials.py 98.29% <100%> (+0.69%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8bde611...725ebd8. Read the comment docs.

Copy link
Copy Markdown
Contributor

@kyleknap kyleknap left a comment

Choose a reason for hiding this comment

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

Looks good. Just had a question and a comment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

One more test that might be good to add is one that checks that it does not refresh the credentials when it is not going to expire any time soon.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

So for the very first time you load credentials and you do not have an expiry time set, it will not ever try to refresh if it you add the expiry time variable later on? I'm just curious about the behavior. Have not really thought out what should be desired.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Correct. I'm not sure how else we would do it without hacks

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah I cannot think of other ways to do this. I guess another question I have is it possible to transition from refershable environment credentials to non-refreshable? So say I had an expiry time set and then unset the expiry time variable before the next refresh what would happen?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It would fail as it expects it to be there upon refresh

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ok cool. That at least ensures the behavior is consistent for both directions (i.e. you can't do it).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think it would good to have tests for these cases (fixed->refreshable, refreshable->fixed are not allowed). Unlike other refreshable providers were it was unlikely to have missing keys across subsequent responses, this is the first refreshable provider that seems more prone to refresh errors.

@JordonPhillips
Copy link
Copy Markdown
Contributor Author

Updated

Copy link
Copy Markdown
Contributor

@kyleknap kyleknap left a comment

Choose a reason for hiding this comment

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

🚢

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I don't think we should rely on no expiry time meaning non-refreshable credentials. I would prefer we're explicit. If we get expiry time use RefreshableCredentials, otherwise use Credentials.

I'm guessing that code was put in place to protect against malformed responses and not necessarily as part of its contract. It's always confusing to have RefreshableCredentials not actually refresh if you don't provide expiry.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

👍 updated

Copy link
Copy Markdown
Member

@jamesls jamesls left a comment

Choose a reason for hiding this comment

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

Looks good to me.

@JordonPhillips JordonPhillips merged commit cb8d4b8 into boto:develop May 5, 2017
@koreno
Copy link
Copy Markdown

koreno commented Jul 20, 2017

How should this feature be used? how would boto refresh the credentials once it finds they've expired?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

pr/needs-review This PR needs a review from a member of the team.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants