-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Add ChallengeAuthenticationPolicy #17489
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
2db24be to
d1870ec
Compare
|
Are you ready to GA? If not, maybe we want to keep it in feature branch. |
|
Yes, we want to GA this next month. |
| # type: () -> bool | ||
| return not self._token or self._token.expires_on - time.time() < 300 | ||
|
|
||
| def authorize_request(self, request, *scopes, **kwargs): |
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.
What is the typical way for users to use the policy? Not in the pipeline?
Why in addition to send, we also need to expose authorize_request, on_request & on_challenge?
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.
In a pipeline. Client library developers should subclass this to accommodate their particular services.
- authorize_request is a helper method for updating the policy's token and authorizing a request
- on_request allows clients to override the policy's default behavior of authorizing requests. For example, Key Vault clients want to send an unauthorized request to elicit an authentication challenge (which would look like this)
- on_challenge is the method client libraries override to implement challenge handling for their particular service (ARM, for example)
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.
To help me understand, do you mean users are not supposed to use it directly. Instead, they should always inherit the class and use the customized one?
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.
If they want to handle authentication challenges. There's no particular reason to use this policy otherwise, although doing so wouldn't break anything. The policy by itself authorizes requests with bearer tokens just 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.
It looks to me we set auth header in both authorize_request & on_request. My understanding is the one in on_request will override authorize_request?
Why user needs to set it twice?
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.
on_request is called first when a request arrives. authorize_request is a helper for subclasses to use, so they don't have to handle the credential or cached token (for example). Assuming neither method is overridden, authorize_request would overwrite a token applied by on_request. Which is fine, the policy is designed for a scenario like this:
- on_request authorizes the request
- policy sends the request to the RP
- RP responds with a challenge
- on_challenge authorizes the request with a new token (perhaps by calling authorize_request)
- policy sends the request to the RP again
0125a62 to
15e2521
Compare
| raise ServiceRequestError( | ||
| "Bearer token authentication is not permitted for non-TLS protected (non-https) URLs." | ||
| ) | ||
| return _enforce_https(request) |
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.
Are you sure you want to use the exactly same method name? Looks confusing. :)
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.
Hmmm I hear you but the good name is taken 🤣
🤷 _enforce_https_impl?
|
|
||
| def _need_new_token(self): | ||
| # type: () -> bool | ||
| return not self._token or self._token.expires_on - time.time() < 300 |
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.
Do we want to make '300' configurable?
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.
Not initially. We could add configuration later.
|
It seems this feature has already been added to the |
|
It's missing from our master branch, but this code is in the latest FYI @jiasli |
|
@chlowell Thanks for the explanation. I actually packaged
From a packager's view, the problem with the Azure SDK and CLI is that some of the individual packages require beta versions of other packages as well, even when these packages have a stable version number themselves. In particular, the Azure CLI packages depend on beta versions. I will update the |
|
Next month's As for this PR, I'm closing it in favor of #18437. |
Clients expecting authentication challenges should subclass ChallengeAuthenticationPolicy and override
on_challengeto handle those challenges.