[core-http] Remove ServiceClientCredentials from ServiceClient API#4367
[core-http] Remove ServiceClientCredentials from ServiceClient API#4367daviwil merged 9 commits intoAzure:masterfrom
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.
Why are the params having underscore here?
There was a problem hiding this comment.
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.
nah, not worth it
this is fine
ramya-rao-a
left a comment
There was a problem hiding this comment.
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
ServiceClientCredentialsfrom thecredentialsparameter onServiceClientso that onlyTokenCredentialimplementations can be used. Those who usems-rest-nodeauthwould 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
RequestPolicyFactorylist with asigningPolicy. I figured it would be better to leaveServiceClientCredentialsandSigningPolicyaround (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
RawTokenCredentiallive in@azure/core-authso that it can be used outside of@azure/core-http, like in@azure/core-amqp?