search

microsoft / AzureStorageExplorer

Easily manage the contents of your storage account with Azure Storage Explorer. Upload, download, and manage blobs, files, queues, tables, and Cosmos DB entities. Gain easy access to manage your virtual machine disks. Work with either Azure Resource Manager or classic storage accounts, plus manage and configure cross-origin resource sharing (CORS) rules.
Creative Commons Attribution 4.0 International
372 stars 85 forks source link

There are three extra actions for one OAuth attached file share #7840

Closed v-xianya closed 2 months ago

v-xianya commented 6 months ago

Storage Explorer Version: 1.34.0-dev (98) Build Number: 20240327.12 Branch: main Platform/OS: Windows 10/Linux Ubuntu 22.04/MacOS Sonoma 14.4(Apple M1 Pro) Architecture: x64/x64/arm64 How Found: From running test cases Regression From: Not a regression

Steps to Reproduce

  1. Expand one storage account -> File Shares.
  2. Select one file share then attach it via OAuth.
  3. After attaching successfully.
  4. Right click the attachment -> Observe its context menu.
  5. Check whether there is no extra action.

Expected Experience

There is no extra action.

Actual Experience

There are three extra actions. image

MRayermannMSFT commented 2 months ago

@v-xianya I understand why Clone and Delete are "extra", but why do you consider create snapshot to be extra?

v-xianya commented 2 months ago

@MRayermannMSFT Refer to one SAS attached file share. there is no 'Create Snapshot' action. So, we guess it might be an extra action for OAuth attached file share.

Also, when executing 'Create Snapshot'. there is a failed activity log with error details:

"name": "RestError", "message": "This request is not authorized to perform this operation.\nRequestId:2e6567cd-301a-005c-2693-d29358000000\nTime:2024-07-10T06:36:19.6209522Z",

image

MRayermannMSFT commented 2 months ago

@v-xianya a couple of things I've learned today:

  1. Delete and clone should be hidden for directly attached file shares and blob containers as a design choice. That is to say, no matter how you authorize a directly attached file share or blob container, we always disable delete and clone. That is because we do not believe something directly attached should be deleted or cloned. A user should be doing that from the context of the storage account (e.g., attaching the storage account, listing the storage account under a subscription, etc.). This is currently broken for file shares.

  2. Create share snapshot is not always hidden for directly attached file shares. If you attach one using an account level SAS, the action is available and works (assuming the right account SAS permissions): image

  3. For an OAuth authenticated direct attached file share, create share snapshot will work if you have an RBAC role that grants the necessary permission (example: Owner).

So, I'm going to:

  1. Fix clone and delete not always being disabled for file shares.
  2. Leave create share snapshot alone, that is:
    • We hide it if we know you can't do it
    • We show it if it looks possible for you to do it
v-xianya commented 2 months ago

Hi @MRayermannMSFT Succeed to create snapshot if have Owner role.

MRayermannMSFT commented 2 months ago

Ok. On builds for main, the actions for clone and delete should be gone now.

v-xianya commented 2 months ago

Verified this issue on the main build 20240726.3. Fixed. Clone and Delete actions have been removed. image