-
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
[core-http] Remove ServiceClientCredentials from ServiceClient API #4367
[core-http] Remove ServiceClientCredentials from ServiceClient API #4367
Conversation
f78c4a8
to
433ef10
Compare
Regarding Azure/ms-rest-nodeauth#66 (comment) , I might have a better heuristic for return credential
&& typeof credential.getToken === "function"
&& (credential.signRequest === undefined || credential.getToken.length > 0); This new logic ensures that if the credential object also has a In other words, this new logic reduces the number of false positives we'd get compared to only checking for the existence of What do you think @bterlson? |
@daviwil seems like a good approach! |
OK, I updated |
e55aead
to
1d3997e
Compare
This rolls back the change made in 771614e because it will prevent forward-compatibility in `ms-rest-nodeauth` and `ms-rest-browserauth` credentials.
1d3997e
to
f8f1304
Compare
export class RawTokenCredential implements TokenCredential { | ||
constructor(token: string, expiresOn?: Date); | ||
expiresOn: Date; | ||
getToken(_scopes: string | string[], _options?: GetTokenOptions): Promise<AccessToken | null>; |
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 the params having underscore here?
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.
They are unused in the scope of this function, adding the _
prefix tells the linter to ignore the fact that they aren't used. I can look into using an eslint rule disable comment instead.
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.
nah, not worth it
this is fine
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 don't like the name RawTokenCredential
, but that doesn't have to block this PR.
Let's log an issue to discuss the name.
Otherwise, things looking good.
Since we have made quite some changes after @amarzavery approved the PR, maybe re-request review?
While waiting on @amarzavery to take another look, how about one of the following names:
Trying to think of something that would make it obvious that it's mostly meant for test purposes. |
Are we sure that this was meant for tests and samples only? |
No, I'm not sure of that, that's why I said "mostly" :) My guess is that it's unlikely anyone would use this in production instead of making their own
|
|
a5e2f24
to
ee97655
Compare
Renamed |
Thanks all! Merging this. |
…4367) * Remove ServiceClientCredentials from ServiceClient API * Remove additional check added to isTokenCredential This rolls back the change made in 771614e because it will prevent forward-compatibility in `ms-rest-nodeauth` and `ms-rest-browserauth` credentials. * Improve RawTokenCredential comment * Improve credential detection logic in ServiceClient * Add isTokenCredential heuristic to identify TokenClientCredentials * Simplify ServiceClient constructor logic around credentials * Move RawTokenCredential from core-http to core-arm * Delete TokenCredentials, update samples to use RawTokenCredential * Rename RawTokenCredential to SimpleTokenCredential
This change removes
ServiceClientCredentials
from thecredentials
parameter onServiceClient
so that onlyTokenCredential
implementations can be used. Those who usems-rest-nodeauth
would be able to leverage the changes in Azure/ms-rest-nodeauth#66 to use those credential types with SDKs using the updatedServiceClient
.It's worth noting that this change does not prevent someone from constructing their own
RequestPolicyFactory
list with asigningPolicy
. I figured it would be better to leaveServiceClientCredentials
andSigningPolicy
around (for now) if someone really needed to use them. We can delete them entirely at a later date if we decide to, or even now if anyone feels strongly that they should be gone.Questions for Reviewers
RawTokenCredential
live in@azure/core-auth
so that it can be used outside of@azure/core-http
, like in@azure/core-amqp
?