Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Azure and mkdir command failed to set container public access level to blob or container #5045

Closed
krmanish opened this issue Feb 18, 2021 · 3 comments · Fixed by #5048
Closed

Comments

@krmanish
Copy link
Contributor

I think instead of keeping the access level to None there are two more options that it should support while using mkdir command.
In place of hardcode PublicAccessNone it should get the options from CLI and set default if missing. Other options are PublicAccessBlob & PublicAccessContainer.

_, err := f.cntURL(container).Create(ctx, azblob.Metadata{}, azblob.PublicAccessNone)

@krmanish krmanish changed the title Azure and replace hardcode container public access level to a variable (to consider other options) Azure and mkdir command failed to set container public access level to blob or container Feb 18, 2021
@ncw
Copy link
Member

ncw commented Feb 19, 2021

You wrote on the forum

I think an additional flag something like --azureblob-public-access with value would suffice here. And this flag would be useful during sync/copy/mkdir command where if the container does not exist (or even exists), it should create with that additional public access level parameter.

azureblob-public-access <blob/container>

Command

rclone mkdir --azureblob-public-access blob azure:mydemocontainer

Does that make sense?

I found the docs for this here: https://docs.microsoft.com/en-us/rest/api/storageservices/create-container

x-ms-blob-public-access Optional. Specifies whether data in the container may be accessed publicly and the level of access. Possible values include:

  • container: Specifies full public read access for container and blob data. Clients can enumerate blobs within the container via anonymous request, but cannot enumerate containers within the storage account.
  • blob: Specifies public read access for blobs. Blob data within this container can be read via anonymous request, but container data is not available. Clients cannot enumerate blobs within the container via anonymous request.

If this header is not included in the request, container data is private to the account owner.

After reading that I think the proposal to make a public_access flag with the string values "none", "container" and "blob" would work very well. It would default to "none". This would then create a command line flag --azureblob-public-access as you suggested.

This would be very easy to implement with a config flag like this one

Name: "filename_encryption",
Help: "How to encrypt the filenames.",
Default: "standard",
Examples: []fs.OptionExample{
{
Value: "standard",
Help: "Encrypt the filenames see the docs for the details.",
}, {
Value: "obfuscate",
Help: "Very simple filename obfuscation.",
}, {
Value: "off",
Help: "Don't encrypt the file names. Adds a \".bin\" extension only.",
},
},

Do you want to have a go at this? The 3 examples can be azblob.PublicAccessNone, azblob.PublicAccessBlob, azblob.PublicAccessContainer and the default can be azblob.PublicAccessNone (not sure what this value actually is!)

@ncw ncw added this to the v1.55 milestone Feb 19, 2021
@krmanish krmanish reopened this Feb 19, 2021
@krmanish
Copy link
Contributor Author

krmanish commented Feb 19, 2021

Thanks! Sure, will give it a try.

@ncw
Copy link
Member

ncw commented Mar 15, 2021

I've merged this to master now which means it will be in the latest beta in 15-30 mins and released in v1.55

Thanks @krmanish for doing this :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants