Azure-sdk-for-js: Can not use Front Door URL for blob storage account in BlobServiceClient for React App

[pritesha]

• Package Name: @azure/storage-blob
• Package Version: 12.2.0-preview.1
• Operating system:
• [ ] nodejs
  
  
  
  • version:
  
  
• [x] browser
  
  
  
  • name/version: Google Chrome/Version 84.0.4147.105 (Official Build) (64-bit)
  
  
• [x] typescript
  
  
  
  • version: 3.9.6
  
  
• Is the bug related to documentation in
  
  
  
  • [ ] README.md
  
  
  • [ ] source code documentation
  
  
  • [ ] SDK API docs on https://docs.microsoft.com
  
  

Describe the bug
We have an Azure Blob Storage Account running behind Azure Front Door to provide custom URL & improve traffic performance.
The react app ( scaffold from CRA), uses the @azure/storage-blob for upload, download, list & delete operations using SASToken.
The App runs fine when running with Blob URL _example - https://example.blob.core.windows.net_ appended with SASToken.
However when it is replaced with Front Door custom URL, BlobServiceClient fails with error :

Error: Unable to extract accountName with provided information.
    at getAccountNameFromUrl (utils.common.ts:556)
    at BlobServiceClient.StorageClient (StorageClient.ts:79)
    at new BlobServiceClient (BlobServiceClient.ts:444)
    at BlobStorageService.init (BlobStorageService.ts:35)

To Reproduce
Steps to reproduce the behavior:

1. Create a Front Door entry for Blob Storage Account URL.
2. Try to create BlobServiceClient as

const customFrontDoorURL = 'https://files.xyz.com';
const blobServiceClient = new BlobServiceClient(`${customFrontDoorURL}/${SASToken}`);

Expected behavior
A valid service client is created.

[kurtzeborn]

We discussed this in storage standup and custom URLs are supported in .NET, Java, and Python for scenarios like this. Seems like support should be added for JS in the same manner.

[jeremymeng]

We assume certain words in the host name and use it to check for ip/localhost case. Regex testing of ip/localhost would be more proper here

export function getAccountNameFromUrl(url: string): string {
  const parsedUrl: URLBuilder = URLBuilder.parse(url);
  let accountName;
  try {
    if (parsedUrl.getHost()!.split(".")[1] === "queue") {
      // `${defaultEndpointsProtocol}://${accountName}.queue.${endpointSuffix}`;
      accountName = parsedUrl.getHost()!.split(".")[0];
    } else {
      // IPv4/IPv6 address hosts... Example - http://192.0.0.10:10001/devstoreaccount1/
      // Single word domain without a [dot] in the endpoint... Example - http://localhost:10001/devstoreaccount1/
      // .getPath() -> /devstoreaccount1/
      accountName = parsedUrl.getPath()!.split("/")[1];
    }

    if (!accountName) {
      throw new Error("Provided accountName is invalid.");
    }
    return accountName;
  } catch (error) {
    throw new Error("Unable to extract accountName with provided information.");
  }
}

[jiacfan]

Through code inspection, accountName in StorageClient.ts is not referenced in product code and only evaluated in the test files.
From scenario aspect, accountName is not necessary for custom domain scenario, and looks like not necessary in context of StorageClient.ts, considering credential has provided enough info for AuthN and AuthZ.
Probing further, method getAccountNameFromUrl is referenced in two places, StorageClient.ts and
extractConnectionStringParts in utils.common.ts for parsing connection string. There is issue in connection string's parsing context as well, where accountName is not necessary to be provided when SAS connection string is used.

My proposal here is to remove the accountName parsing error in both places considering accountName is not essential for all scenarios. and we can leave accountName as empty (or undefined with breaking change to make the variable nullable) if it's e.g. in custom domain scenario, @jeremymeng @XiaoningLiu what's your ideas?

Thanks,
Jiachen

[jeremymeng]

We added various names properties to clients for convenience, e.g., service client has accountName, container client has containerName, blob client has contsinerName and name. It is across all languages. I think we need to fix the parsing logic to work with custom domain names.

[jiacfan]

@jeremymeng In custom domain name scenario, there would be no valid account name specified from SAS. So in that case account name will be unknown.

[pritesha]

Thanks guys for the quick response. By the time this bug is fixed & released, is there any workaround ?
P.S. We are not using accountName ( & pretty sure wont use it in any future scenarios).

[jeremymeng]

My proposal here is to remove the accountName parsing error in both places considering accountName is not essential for all scenarios. and we can leave accountName as empty (or undefined with breaking change to make the variable nullable) if it's e.g. in custom domain scenario, @jeremymeng @XiaoningLiu what's your ideas?

Sorry I misread this part and thought about removing accountName. Yes I like this approach: removing validation of accountName and leave it empty in the case where it is not available.

By the time this bug is fixed & released, is there any workaround ?

@pritesha other than patching our code manually I don't know an easy workaround.

[jiacfan]

Hi, @pritesha

Custom domain support has been released with @azure/storage-blob 12.2.0, welcome to have a try.

Thanks,
Jiachen

[jiacfan]

Closing the issue as custom domain support has been released. Welcome leave message if need further assistant.

Thanks,
Jiachen

[pritesha]

Thanks @jiacfan.