[Feature Request] BlobContainerClient should validate the Uri include a container name about azure-sdk-for-net HOT 8 OPEN

@wghilliard: Yes, that's what it appears to be. You're creating a BlobContainerClient without a container name. To do so, you'd either need to form the URL with the container name:

var containerClient = new BlobContainerClient(new Uri("https://nyancat.blob.core.windows.net/mycontainer"), tokenCredential);

or use a BlobServiceClient to build the container client:

var containerClient = new BlobServiceClient(new Uri("https://nyancat.blob.core.windows.net"), tokenCredential)
    .GetBlobContainerClient("mycontainer");

Given this was perhaps caused by user error, could we add validation to the BlobContainerClient constructor to ensure the URI is the shape it is expecting?

I agree that would be a good idea. I'll update the title and leave this open for the Azure Storage team to review/consider, as the owners of the Storage SDK packages.

//cc: @amnguye

from azure-sdk-for-net.

I could see the SDK providing a way to validate blob container Uri's, to validate the name is in the URL.

This does require us to make sure we cover all our bases with every single type of storage Uri out there (e.g. host IP style endpoints).

Today we don't have checks on the Uri passed to any storage client constructor. I believe adding these checks wouldn't break any happy path behavior (since people would know they passed an invalid Uri eventually, when they go to make an API call).

I wonder though if it does break those who are mocking the storage clients (e.g. BlobContainerClient), handing it a bad Uri and just expecting it to work. Just a thought.

@seanmcc-msft @jaschrep-msft Are we good to just throw an ArgumentException in this case? We can easily reuse the BlobUriBuilder to validate for us.

from azure-sdk-for-net.

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

from azure-sdk-for-net.

Hi @wghilliard: Thanks for reaching out and we regret that you're experiencing difficulties. The Event Hubs library does not directly interact with storage; it makes use of the Azure Storage library for all storage operations, using the BlobContainerClient that you pass to it as part of construction. As this lies outside of Event Hubs, the Azure Storage team has been looped in to offer assistance.

I don't believe this is related to token credential use, as this scenario has a comprehensive suite of tests that cover it and run nightly. I see no failures, I am not able to reproduce locally, and we have no other reports of this failure when using credentials. More likely, I suspect that the failure that you're seeing may have something to do with the BlobContainerClient configuration.

Please provide a code snippet that demonstrates how you're constructing your BlobContainerClient, using the exact container name that you're using, if possible, or if that contains sensitive information, a container name that uses the exact same pattern.

from azure-sdk-for-net.

Hi @wghilliard. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue.

from azure-sdk-for-net.

I think the error could be in how the path is being constructed when performing the partition ownership check, note the trailing slash in the query

QueryParameterName: prefix
QueryParameterValue: nyancat.servicebus.windows.net/mynamespace/myconsumergroup/ownership/

Here is the snippet demonstrating how I'm constructing the BlobContainerClient

new BlobContainerClient(new Uri("https://nyancat.blob.core.windows.net/"), tokenCredential);

from azure-sdk-for-net.

It seems like perhaps the exception might be caused by not providing a suffixed container name in the URI. After appending it, I think the SDK is working as expected (currently attempting to get role assignments sorted out such that I can test).

Given this was perhaps caused by user error, could we add validation to the BlobContainerClient constructor to ensure the URI is the shape it is expecting?

from azure-sdk-for-net.

That's a good point about mocks, perhaps the builder or an option during construction to run / suppress validation??

from azure-sdk-for-net.