-
Notifications
You must be signed in to change notification settings - Fork 314
Using TokenCredential trait in KeyVaultClient #10
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
Conversation
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. |
There was a problem hiding this 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.
There was a problem hiding this 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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
azure-sdk-for-rust/sdks/cosmos/src/clients/collection_struct.rs
Lines 24 to 37 in 8e5f133
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.
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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()) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 if you have issues with the above and have suggestion how to fix/improve them, could you please create a ticket ? |
@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. |
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 !