Skip to content
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

Merged
merged 9 commits into from
Jul 25, 2019

Conversation

daviwil
Copy link
Contributor

@daviwil daviwil commented Jul 19, 2019

This change removes ServiceClientCredentials from the credentials parameter on ServiceClient so that only TokenCredential implementations can be used. Those who use ms-rest-nodeauth would be able to leverage the changes in Azure/ms-rest-nodeauth#66 to use those credential types with SDKs using the updated ServiceClient.

It's worth noting that this change does not prevent someone from constructing their own RequestPolicyFactory list with a signingPolicy. I figured it would be better to leave ServiceClientCredentials and SigningPolicy 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

  • Should RawTokenCredential live in @azure/core-auth so that it can be used outside of @azure/core-http, like in @azure/core-amqp?

@daviwil daviwil changed the title Remove ServiceClientCredentials from ServiceClient API [core-http] Remove ServiceClientCredentials from ServiceClient API Jul 19, 2019
@daviwil daviwil force-pushed the adieu-service-client-credentials branch from f78c4a8 to 433ef10 Compare July 19, 2019 22:34
@daviwil
Copy link
Contributor Author

daviwil commented Jul 22, 2019

Regarding Azure/ms-rest-nodeauth#66 (comment) , I might have a better heuristic for isTokenCredential that may not be 100% perfect but more reliable than just checking for getToken on the credential object. I looked into function.length and it appears to be supported across all browser JS engines. With that in mind, the logic for isTokenCredential could be changed to the following:

  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 signRequest method, that the getToken method be defined to take a non-zero number of parameters. My theory is that this scopes the length check to only be applicable when the credential might also be a ServiceClientCredential so that if getToken.length returns 0 on a particular platform when it should be non-zero, at least we're wrong only when we have good reason to suspect the credential might just be a ServiceClientCredential that also implements TokenClientCredentials.

In other words, this new logic reduces the number of false positives we'd get compared to only checking for the existence of getToken on the credential object and it definitely helps to avoid the case where someone tries to use a credential from an incompatible version of ms-rest-nodeauth and succeeds, resulting in errors.

What do you think @bterlson?

@bterlson
Copy link
Member

@daviwil seems like a good approach!

@daviwil
Copy link
Contributor Author

daviwil commented Jul 22, 2019

OK, I updated isTokenCredential with the proposed changes and it seems to work as expected both with the current ms-rest-nodeauth (returns false on those credentials) and the updated version that is compatible with TokenCredential (returns true for those credentials). Can you take another look @ramya-rao-a?

@daviwil daviwil force-pushed the adieu-service-client-credentials branch 2 times, most recently from e55aead to 1d3997e Compare July 22, 2019 20:31
@daviwil daviwil force-pushed the adieu-service-client-credentials branch from 1d3997e to f8f1304 Compare July 23, 2019 19:33
export class RawTokenCredential implements TokenCredential {
constructor(token: string, expiresOn?: Date);
expiresOn: Date;
getToken(_scopes: string | string[], _options?: GetTokenOptions): Promise<AccessToken | null>;
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 the params having underscore here?

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

@ramya-rao-a ramya-rao-a left a 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?

@daviwil daviwil requested a review from amarzavery July 23, 2019 21:43
@daviwil
Copy link
Contributor Author

daviwil commented Jul 23, 2019

While waiting on @amarzavery to take another look, how about one of the following names:

  • BareTokenCredential
  • StringTokenCredential
  • BasicTokenCredential
  • SampleTokenCredential
  • TestTokenCredential

Trying to think of something that would make it obvious that it's mostly meant for test purposes.

@ramya-rao-a
Copy link
Contributor

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?

@daviwil
Copy link
Contributor Author

daviwil commented Jul 23, 2019

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 TokenCredential implementation (or ServiceClientCredentials in the past).

SimpleTokenCredential could be another option.

@ramya-rao-a
Copy link
Contributor

SimpleTokenCredential is my winner with BasicTokenCredential as a runner up

@daviwil daviwil force-pushed the adieu-service-client-credentials branch from a5e2f24 to ee97655 Compare July 25, 2019 21:47
@daviwil
Copy link
Contributor Author

daviwil commented Jul 25, 2019

Renamed RawTokenCredential to SimpleTokenCredential in the latest change.

@daviwil
Copy link
Contributor Author

daviwil commented Jul 25, 2019

Thanks all! Merging this.

@daviwil daviwil merged commit 0a46246 into Azure:master Jul 25, 2019
@daviwil daviwil deleted the adieu-service-client-credentials branch July 25, 2019 23:03
HarshaNalluru pushed a commit that referenced this pull request Aug 2, 2019
…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
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.

4 participants