[FEATURE REQUEST] Equivalent to StorageCredentials.IsSAS in Storage v12

[SeanFeldman]

Query/Question

I'm looking for an equivalent to Storage v11 in v12.

With v12, when creating a BlobContainerClient, I can pass in either a StorageSharedKeyCredentials, a connection/SAS string, or a TokenCredential.

In v11, when passing a connection/SAS and constructing a StorageCredentials object, there was an IsSAS property that could differentiate between a connection string and a SAS string. With v12 it seems as this option was lost and the code has to explicitly distinguish between a connection string vs SAS Uri. Also, there's no way to

Environment:

• Name and version of the Library package used: [e.g. Azure.Storage.Blobs 12.2.0]
• Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): [e.g. Azure AppService or Windows 10 .NET Framework 4.8]
• IDE and version : [e.g. Visual Studio 16.3]

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

[seanmcc-msft]

V12 doesn't have a StorageCredentials class, we have StorageSharedKeyCredential for shared key and connection string, TokenCredential for Oauth, and no auth class for SAS, since we consider it part of the URI.

Which scenario you are running into issues with?

[SeanFeldman]

When using a connection string, I want to be able to identify a SAS based authentication. This was done OOTB by StorageCredentials in v11.

[seanmcc-msft]

What do you mean by "identify a SAS based authentication"?

[SeanFeldman]

A URI could be with or w/o a SAS token. What's the option to verify the query string of the URI is a valid SAS token with v12?

[SeanFeldman]

@seanmcc-msft, some of this could be addressed by fixing #11590 which would provide an option to parse a connection string and get all the parts. I'm surprised to see connection string parsing to construct a domain object was removed in v12. All the properties/parts are still valid as the service side did not change. SAS tokens, endpoints, endpoint suffixes, etc are still the same concepts.

[ghost]

Hi @SeanFeldman. Thank you, for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[ghost]

Hi @SeanFeldman. There was a mistake and this issue was unintentionally flagged as a stale pull request. The label has been removed and the issue will remain active; no action is needed on your part. Apologies for the inconvenience.

[greatvovan]

@seanmcc-msft when using Integrated Windows Authentication which of TokenCredential's descendants should I use? Cannot figure out...

AcquireTokenByIntegratedWindowsAuth() already returns a token as a property of AuthenticationResult instance. TokenCredential with its GetToken() seems redundant.

If I got the token using AcquireTokenByIntegratedWindowsAuth() I need to supply it somehow to BlobContainerClient, or alternatively I need a TokenCredential instance that would acquire a token for me.

Please suggest.

[JimSuplizio]

Hi @SeanFeldman, 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.