question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[FEATURE REQ] Make the process of using a CustomerProvidedKey with BlobClient more DI-friendly

See original GitHub issue

Library or service name. Azure.Storage.Blobs

Is your feature request related to a problem? Please describe. Currently, the process of setting up a BlobClient instance to use a CustomerProvidedKey in projects that leverage DI (e.g., and ASP.NET Core project) is very annoying.

You can inject BlobServiceClient via DI, and obviously you can create BlobContainerClients and BlobClients using the injected BlobServiceClient instance. That’s great for normal usage…but as soon as I need to create a BlobClient that uses a CustomerProvidedKey, it becomes frustrating, because:

  • CustomerProvidedKey must be passed via BlobClientOptions
  • The only way to pass BlobClientOptions to BlobClient is via its constructors, there’s no other way via the “normal” BlobServiceClient -> BlobContainerClient -> BlobClient route.
  • To make things even more annoying, there’s nothing I can “get” from the injected BlobServiceClient and pass to the BlobClient constructor to let me “inherit” the identity, URI, etc in that fashion.

So what you end up with is a situation where your DI-injected BlobServiceClient becomes useless, and you have to inject all of the information needed to set up a brand new BlobClient instance using IOptions<Foo> (or something similar).

For my specific use-case, we generate new encryption keys for each new blob we upload, so I’ve basically ended up creating a BlobClient factory and inject that via DI, but it would really be preferable if there were some way to just create the BlobClient via BlobServiceClient I’m already injecting for other reasons.

If there were an extra overload of BlobContainerClient.GetBlobClient() that took a second parameter of type BlobClientOptions (or perhaps simply CustomerProvidedKey), that would be excellent.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:11 (7 by maintainers)

github_iconTop GitHub Comments

1reaction
seanmcc-msftcommented, Apr 14, 2021

@tg-msft, just want to double check, we are cool with:

  • BlobServiceClient.WithCustomerProvidedKey(CustomerProvidedKey customerProvidedKey)
  • BlobContainerClient.WithCustomerProvidedKey(CustomerProvidedKey customerProvidedKey)
  • BlobBaseClient.WithCustomerProvidedKey(CustomerProvidedKey customerProvidedKey)

We could also consider adding WithEncryptionScope(), since the idea is essentially the same.

1reaction
seanmcc-msftcommented, Apr 14, 2021

Ok, I will work on this this week.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Specify a customer-provided key on a request to Blob ...
This article shows how to specify a customer-provided key on a request with .NET. Install client library packages. Note. The examples shown here ......
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found