Generate SAS on file share folders incorrectly generates share level SAS

[MaStr11]

Storage Explorer Version: 1.8.1
Platform/OS: Windows 10
Architecture: x64
Regression From: -

Bug description
A SAS token generated for a StorageV2 account file share folder is invalid.

Steps to Reproduce

1. Create a StorageV2 File Share
2. Create a Folder within the file share
3. Click Get Shared Access Signature

Expected Experience
The generated SAS url is working.

Actual Experience
Accessing the resource failes with 400 The specifed resource name contains invalid characters.

Request
https://<omitted>.file.core.windows.net/hierachie/Test/?st=2019-05-15T07%3A27%3A49Z&se=2019-05-16T07%3A27%3A49Z&sp=rl&sv=2018-03-28&sr=s&sig=MUc3WSaBgNuDHlo%2FeiTaQDrGcxRMay9tNwdruXR7j%2F8%3D

Response

• HTTP Status Code: 400 The specifed resource name contains invalid characters.

<Error>
  <Code>InvalidResourceName</Code>
  <Message>
    The specifed resource name contains invalid characters. RequestId:414c0fff-101a-0074-45f2-0a788b000000 Time:2019-05-15T07:49:00.7022059Z
  </Message>
</Error>

Additional Context
The problem seems to be related to the trailing slash in the path file.core.windows.net/hierachie/Test/. Removing the / results in a 404 The specified resource does not exist. response.

According to the documentation SAS should work for folders:

Is it possible to specify read-only or write-only permissions on folders within the share?

If you mount the file share by using SMB, you don't have folder-level control over permissions. However, if you create a shared access signature by using the REST API or client libraries, you can specify read-only or write-only permissions on folders within the share.

[MaStr11]

After further investigation, it seems that the storage explorer is creating a sas for the whole share (&sr=s).
The SAS can be used to access any file regardless of the folder it lives in. So the access to a file outside the "Test" folder is working:
https://<omitted>.file.core.windows.net/hierachie/SampleFile.txt?st=2019-05-15T07%3A27%3A49Z&se=2019-05-16T07%3A27%3A49Z&sp=rl&sv=2018-03-28&sr=s&sig=MUc3WSaBgNuDHlo%2FeiTaQDrGcxRMay9tNwdruXR7j%2F8%3D

This seems to be a limitation of the SAS not being able to sign directories (the Signed Resource parameter for file storage is only supporting f for file and s for shares according to the docs).

I keep the issue open nevertheless to get some feedback regarding the SAS limitation because it is contradictionary to the FAQ (However, if you create a shared access signature by using the REST API or client libraries, you can specify read-only or write-only permissions on folders within the share.).

[MRayermannMSFT]

Hey @MaStr11, thanks for opening this issue. This is something we'll have to dig more into. We'll reply with further updates when we get to doing that.

[JasonYeMSFT]

It seems like the platform is using "restype=directory" to distinguish folders and files. We will fix it and make folder sas work as well as file sas.

[haldarsumana]

I am facing the same issue. Sastoken for a directory in file share is able to access other directory's file as well. Is this issue is still open? Is there any way around in any language that I can get a sasToken only for a specific directory in file share by using the rest api or library?

[JasonYeMSFT]

@haldarsumana This issue is still open. And I was wrong, after more investigation, I found that SAS for accessing a directory and files in that directory isn't supported. When we pass the directory path to the SDK, The SDK internal logic decides that if no file is provided, it will create a share level SAS and that is why we are accidentally creating share level SAS. We will disable the get sas action on files.