Should we requrie AZURE_USERNAME being set to use the shared cache from DefaultAzureCredential?
#7944
Labels
Azure.Identity
blocking-release
Blocks release
Client
This issue points to a problem in the data-plane of the library.
Comments
loarabia
added
Azure.Identity
Client
|
FWIW, I prototyped this a little here: https://gist.github.com/ellismg/302cfc8cc6b34b5698642f512df26fa3. I'm no python expert but maybe this a reasonable starting point if we want to do this for GA. |
ellismg
added a commit
to ellismg/azure-sdk-for-python
that referenced
this issue
Oct 24, 2019
Previously, a username was required when using the SharedTokenCacheCredential, in order to handle the case where multiple identities were found in the cache. Since it is common to have only a single account in your user cache (e.g. you have signed in with only a single identity), we should allow reading from the cache even when an explicit AZURE_USERNAME is not specified, if there is exactly one account in the cache. When username is unset, if we can not find a token in the cache or we find multiple tokens, a `ClientAuthenticationError` error is raised, with the text "No cached token found". This is similar to how other cache related failures are handled by the API (they raise this error with similar text but it includes a hint about what username was used.) As part of this work, `DefaultAzureCredential` now unconditionally uses the shared cache on supported platforms. This behavior matches how we handle this case in both the .NET and Java SDKs. Fixes Azure#7944
ellismg
added a commit
that referenced
this issue
Oct 24, 2019
Previously, a username was required when using the SharedTokenCacheCredential, in order to handle the case where multiple identities were found in the cache. Since it is common to have only a single account in your user cache (e.g. you have signed in with only a single identity), we should allow reading from the cache even when an explicit AZURE_USERNAME is not specified, if there is exactly one account in the cache. When username is unset, if we can not find a token in the cache or we find multiple tokens, a `ClientAuthenticationError` error is raised, with the text "No cached token found". This is similar to how other cache related failures are handled by the API (they raise this error with similar text but it includes a hint about what username was used.) As part of this work, `DefaultAzureCredential` now unconditionally uses the shared cache on supported platforms. This behavior matches how we handle this case in both the .NET and Java SDKs. Fixes #7944
fengzhou-msft
pushed a commit
that referenced
this issue
Nov 5, 2019
Previously, a username was required when using the SharedTokenCacheCredential, in order to handle the case where multiple identities were found in the cache. Since it is common to have only a single account in your user cache (e.g. you have signed in with only a single identity), we should allow reading from the cache even when an explicit AZURE_USERNAME is not specified, if there is exactly one account in the cache. When username is unset, if we can not find a token in the cache or we find multiple tokens, a `ClientAuthenticationError` error is raised, with the text "No cached token found". This is similar to how other cache related failures are handled by the API (they raise this error with similar text but it includes a hint about what username was used.) As part of this work, `DefaultAzureCredential` now unconditionally uses the shared cache on supported platforms. This behavior matches how we handle this case in both the .NET and Java SDKs. Fixes #7944
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The justification for requiring
AZURE_USERNAMEis that the MSAL cache may contain multiple identities, and we need to know which user you want to identify as. However, it seems like the common case is that a single identity will be in the cache and in that case we could just use that identity, even ifAZURE_USERNAMEwas unset.In Azure/azure-sdk-for-net#7947 we changed the .NET Version of
DefaultAzureCredentialto behave in a similar manner (by default, if the cache contains exactly one entry, we'll use it, and if there are multiple identities, you set the preferred username on an options bag when constructing the credential.I am wondering if we should make similar changes here, so things work out of the box in the common case.
The text was updated successfully, but these errors were encountered: