-
Notifications
You must be signed in to change notification settings - Fork 206
Implementing known_authority_hosts #492
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
cf5f9ab
to
0c2a9a3
Compare
080061d
to
8370a61
Compare
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.
Added a few comments but looks good.
Azure CLI never used
For example, to verify with
|
7fe661a
to
260450c
Compare
8a5905e
to
eeae9a5
Compare
Also test behaviors for instance metadata Address proofreading feedback Rename known_authorities to known_authority_hosts Plan to ship this in 1.19 Address feedback from Xiang Yan from Azure SDK team Fine tune some wording known_authority_hosts allows multiple setting but only one modification Refine test case for idempotency More descriptive test case names Use base ClientApplication to test both PCA and CCA
296197e
to
35e00a3
Compare
35e00a3
to
20c0da3
Compare
self, instance_metadata, known_to_microsoft_validation, _): | ||
app = msal.ClientApplication("id", authority="https://login.microsoftonline.com/common") | ||
known_to_microsoft_validation.assert_not_called() | ||
app.get_accounts() # This could make an instance metadata call for authority aliases |
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.
Is it expected in this case that get_accounts()
does instance discovery? That is to say, ClientApplication()
doesn't call known_to_microsoft_validation
but get_accounts()
does.
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.
The answer is two-fold.
- The "validating whether an input authority looks legit" and "getting some metadata for alias grouping" are two different things. This test case, as described in line 141, made a point that one does not necessarily turn off the other. In this case,
ClientApplication()
skips validation, butget_accounts()
would like to know alias groups. - The actual timing of when to send out the metadata call, is an implementation detail. Since MSAL Python delays that metadata call to
get_accounts()
, so this test case is written this way. Your MSAL's implementation does not have to callget_accounts()
.
Last but not least, this entire PR has been shelved, because later we discovered some new requirements for Azure Stack scenarios (internal link), so we proceeded with #496.
Closing this without merging, because we ended up going with #496 |
Implementing the known_authorities behaviors based on the internal design.
The unit tests of this PR is almost as readable as plain English, and are considered as generic acceptance tests for this feature.
This PR also contains the "api reference documentation" for the newly introduced
known_authority_hosts
parameter.When merged, this PR will close this internal workitem.
This entire PR has been shelved, because later we discovered some new requirements for Azure Stack scenarios (internal link), so we proceeded with #496.