AzureBlobStorage token-based authentication

[ntyrrell]

Good day,

I was looking at using this library in conjunction with ImageSharp as we do a fair amount of image processing.

However, I noticed that both AzureBlobStorageCacheOptions and AzureBlobStorageImageProviderOptions only allow for the specification of connection strings. Given that Microsoft now recommend using token-based authentication, it might be preferable to instead allow for using token credentials instead.

At the same time, would it make sense to use an injected BlobServiceClient, rather than instantiating BlobContainerClient directly?

[ntyrrell]

Somewhat tangentially related to this, but rather than having a fixed list of container names, if we were to use a BlobServiceClient, might we also be able to have dynamic container names?

To offer a hypothetical scenario - if I were to have my image data for all customers stored within a single azure storage account, but each customer's image data is stored in its own container, each with a unique name (i.e. a GUID value). The advantages of this approach would be that our customer data isn't interspersed with one another, and we can perform operations on a single customer's data (e.g. move, delete, etc) with relative ease.

The issue with the current implementation is that the container names need to be specified at startup, and we could have tenant operations (CRUD) happening after launch.

[stefannikolei]

@ntyrrell You can always implement your own ImageProvider to exactly match your use case, so this can remain basic and does not open a wide attack surface. Having an dynamic approach will also need some kind of authorization and that is most of the time custom code.