You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Async credential classes missing from azure.identity.aio #19943
The implementations don't exist at all. I was trying to implement an asyncio application using InteractiveBrowser and DeviceCodeCredential, only to find they don't exist
Thanks for opening this issue! An async AzureApplicationCredential does exist but wasn't importable from azure.identity.aio. #19961 fixes that.
The other credentials you list don't exist because their implementation relies on MSAL Python, which doesn't yet have an async API (AzureAD/microsoft-authentication-library-for-python#88). Our #6354 tracks the SDK work needed to use an async MSAL once it exists. One workaround in the meantime is to wrap a blocking credential, for example:
I had a different work-around for this problem but I see there is a tidier one above; it is useful because the pandas.read_parquet() uses packages ffspec and adlfs which only accept async credentials.
fromazure.identityimportInteractiveBrowserCredentialimportpandasimportfunctoolsimportasyncio# define an async wrapperdefrun_in_executor(f):
@functools.wraps(f)definner(*args, **kwargs):
loop=asyncio.get_running_loop()
returnloop.run_in_executor(None, lambda: f(*args, **kwargs))
returninner# apply the wrapper to the get_token function of the credentialinteractive_browser_credential_async=InteractiveBrowserCredential()
interactive_browser_credential_async.get_token=run_in_executor(interactive_browser_credential_async.get_token)
# use the wrapped credential in async context:df=pandas.read_parquet(
f"abfss://{conainter}@{account_name}.dfs.core.windows.net/{path_to_parquet}",
storage_options={
"credential":interactive_browser_credential_async,
}
)
Also works for DeviceCodeCredential. Have not tested the others. Very handy for testing and debugging until scripts are deployed to environments that have better options.
Over the last 2 years several workaround have been reported and implemented, e.g., #19943 (comment) and microsoft/azure-quantum-python#162. However none of these provide a smooth integration with AzureDefaultCredential.
In the absence of an async MSAL, one could just provide a class that uses the sync version and runs the methods in an executor like Nicholas Archer (@MrNickArcher) posted above.
Most users probably don't care about where the asynchronous-ness comes from. As long as it provides any async API, it will work with packages that depend on azure-identity's async auth implementations (such as adlfs, ffspec).
I see that Xiang Yan (@xiangyan99) has been assigned to this issue. Is solving this any priority at all?
Upon having a second look, I do not see how the PR you linked (#30381) solves this problem.
This issue is about not having async credentials implemented for all credential types (e.g., InteractiveBrowserCredential). The PR you linked allows async credentials in sync contexts IIUC. Am I missing some key point perhaps? 😅
Hi Anthony Shaw (@tonybaloney), we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.
Activity
Workaround for Azure/azure-sdk-for-python#19943
chlowell commentedon Jul 27, 2021
Thanks for opening this issue! An async AzureApplicationCredential does exist but wasn't importable from
azure.identity.aio. #19961 fixes that.The other credentials you list don't exist because their implementation relies on MSAL Python, which doesn't yet have an async API (AzureAD/microsoft-authentication-library-for-python#88). Our #6354 tracks the SDK work needed to use an async MSAL once it exists. One workaround in the meantime is to wrap a blocking credential, for example:
Add an async workspace API (#95)
Add an async workspace API (#95)
Add asynchronous workspace (#162)
MrNickArcher commentedon Jan 24, 2023
I had a different work-around for this problem but I see there is a tidier one above; it is useful because the
pandas.read_parquet()uses packagesffspecandadlfswhich only accept async credentials.Also works for
DeviceCodeCredential. Have not tested the others. Very handy for testing and debugging until scripts are deployed to environments that have better options.basnijholt commentedon May 12, 2023
Over the last 2 years several workaround have been reported and implemented, e.g., #19943 (comment) and microsoft/azure-quantum-python#162. However none of these provide a smooth integration with
AzureDefaultCredential.In the absence of an async MSAL, one could just provide a class that uses the sync version and runs the methods in an executor like Nicholas Archer (@MrNickArcher) posted above.
Most users probably don't care about where the asynchronous-ness comes from. As long as it provides any async API, it will work with packages that depend on azure-identity's async auth implementations (such as adlfs, ffspec).
I see that Xiang Yan (@xiangyan99) has been assigned to this issue. Is solving this any priority at all?
(edit: the async MSAL issue has been open for almost 4 years, so I wouldn't expect them to implement this any time soon (AzureAD/microsoft-authentication-library-for-python#88))
xiangyan99 commentedon May 12, 2023
This could be one of the answers. :)
#30381
basnijholt commentedon May 12, 2023
Xiang Yan (@xiangyan99), thanks for your quick reply.
If that works, great!
Otherwise one could do something like:
xiangyan99 commentedon May 12, 2023
Sorry I forgot. In the meanwhile, you can also use this one:
https://gist.github.com/xiangyan99/79004beae47179f8b17bf5bc61b3fc62
(This just offers another option. Your sample works too.)
lmazuel commentedon May 12, 2023
Xiang Yan (@xiangyan99) anything we should do for the June release?
xiangyan99 commentedon May 12, 2023
Let us have a discussion on #30381 and if this one looks good, we can add it into June release.
basnijholt commentedon May 22, 2023
Upon having a second look, I do not see how the PR you linked (#30381) solves this problem.
This issue is about not having async credentials implemented for all credential types (e.g.,
InteractiveBrowserCredential). The PR you linked allows async credentials in sync contexts IIUC. Am I missing some key point perhaps? 😅xiangyan99 commentedon May 23, 2023
w/ this PR, you can use the sync credential in the place that needs async type.
Does this work?
github-actions commentedon Mar 15, 2024
Hi Anthony Shaw (@tonybaloney), we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.