Skip to content

Conversation

gzp79
Copy link
Contributor

@gzp79 gzp79 commented Oct 9, 2020

resolve #5

ClientSecretCredential is used in examples to have the least change (the same env should result in the same response), but for the doc-examples I've used the DefaultCredentail.

As it is a breaking change the semver should be updated before releasing a new version of the crate !

@ghost
Copy link

ghost commented Oct 9, 2020

CLA assistant check
All CLA requirements met.

@gzp79 gzp79 changed the title Issue 5 Using TokenCredential trait in KeyVaultClient Oct 9, 2020
@ctaggart
Copy link
Contributor

Can you merge in latest from master to turn CI green?

@gzp79 gzp79 requested a review from ctaggart October 12, 2020 07:13
@gzp79
Copy link
Contributor Author

gzp79 commented Oct 12, 2020

Can you merge in latest from master to turn CI green?

I think CI also depends on test, but I need to know what is the plan. If DeafaultCrendentials should be used or the ClientSecretCredential and preserve the dependency on the ENV as it is right now.

@gzp79 gzp79 marked this pull request as ready for review October 13, 2020 14:10
Copy link
Contributor

@ctaggart ctaggart left a comment

Choose a reason for hiding this comment

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

Looks great! Just moving async-trait is all I noticed.

@gzp79 gzp79 requested a review from ctaggart October 14, 2020 06:36
Copy link
Contributor

@rylev rylev 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. I have some questions, but nothing that should prevent merging.

pub(crate) aad_tenant_id: &'a str,
pub struct KeyVaultClient<'a, T> {
pub(crate) token_credential: &'a T,
pub(crate) keyvault_name: &'a str,
Copy link
Contributor

Choose a reason for hiding this comment

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

Why are we borrowing the keyvalue_name and token_credential instead of just taking ownership?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was the original implementation and I left it as it was.

Copy link
Contributor

Choose a reason for hiding this comment

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

It would be ergonomic to leave the choice to the caller, for example using Cow. For example CosmosDB uses this pattern:

impl<'a, C, D> CollectionStruct<'a, C, D>
where
C: CosmosClient + Clone,
D: DatabaseClient<C> + Clone,
{
#[inline]
pub(crate) fn new(database_client: Cow<'a, D>, collection_name: Cow<'a, str>) -> Self {
Self {
database_client,
collection_name,
p_c: PhantomData {},
}
}
}

The only limitation is the cloneability of the inner type, something like:

pub struct KeyVaultClient<'a, T: Clone> {
    pub(crate) token_credential: Cow<'a, T>,

Or we can try the MaybeOwned crate that relaxes this limitation. We should probably leave this as a separate PR.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure we really need to care too deeply about the performance implications here. Taking a String and risky some additional heap allocations is fine IMO

aad_tenant_id: &'a str,
token_credential: &'a T,
keyvault_name: &'a str,
endpoint_suffix: String,
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this was like this before, but since we're feeding this into a format! macro, it seems more wise to take endpoint_suffix as a &str.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above, original code. I don't know about original intents.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree, an oversight on my end.


pub(crate) async fn refresh_token(&mut self) -> Result<(), KeyVaultError> {
if matches!(self.token_expiration, Some(exp) if exp > chrono::Utc::now()) {
if matches!(&self.token, Some(token) if token.expires_on > chrono::Utc::now()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Just curious, should we provide some sort of buffer where we refresh the token even if its technically still valid? If the token is valid for 1ns more we won't refresh even though we arguably should.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I made no logic change here either. It was the original implementation.

Copy link
Contributor

Choose a reason for hiding this comment

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

@rylev I kept it simple, refreshing the token would be a great improvement.

@rylev rylev requested a review from guywaldman October 14, 2020 11:09
@gzp79 gzp79 requested a review from rylev October 14, 2020 12:42
@gzp79
Copy link
Contributor Author

gzp79 commented Oct 14, 2020

Looks good. I have some questions, but nothing that should prevent merging.

@rylev if you have issues with the above and have suggestion how to fix/improve them, could you please create a ticket ?
If I have the time I may take a look at it. I wanted to change no logic only perform as much modification as required to allow managed identity and other type of authentication to work smoothly with the keyvault. You might also consider adding the removal of unwrap from the token secret usages and let refresh_token return it. Thus the number of unwrap greatly decreases in the crate.

@rylev
Copy link
Contributor

rylev commented Oct 14, 2020

@gzp-crey sorry, those comments weren't really meant for you since they aren't directly about your changes. I just wanted to mark them so I wouldn't figure them. I can make issues for them.

@rylev rylev mentioned this pull request Oct 14, 2020
@rylev rylev merged commit 9fc1dea into Azure:master Oct 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow keyvault to use the azure_sdk_auth_aad::DefaultCredential for client creation

5 participants