Class representing a storage account, exposing methods for working with it.
The following methods are available, in addition to those provided by the AzureRMR::az_resource class:
new(...): Initialize a new storage object. See 'Initialization'.
list_keys(): Return the access keys for this account.
get_account_sas(...): Return an account shared access signature (SAS). See 'Creating a shared access signature' below.
get_user_delegation_key(...): Returns a key that can be used to construct a user delegation SAS.
get_user_delegation_sas(...): Return a user delegation SAS.
revoke_user_delegation_keys(): Revokes all user delegation keys for the account. This also renders all SAS's obtained via such keys invalid.
get_blob_endpoint(key, sas): Return the account's blob storage endpoint, along with an access key and/or a SAS. See 'Endpoints' for more details
get_file_endpoint(key, sas): Return the account's file storage endpoint.
regen_key(key): Regenerates (creates a new value for) an access key. The argument
key can be 1 or 2.
Initializing a new object of this class can either retrieve an existing storage account, or create a account on the host. Generally, the best way to initialize an object is via the
list_storage_accounts methods of the az_resource_group class, which handle the details automatically.
Note that you don't need to worry about this section if you have been given a SAS, and only want to use it to access storage.
AzureStor supports generating three kinds of SAS: account, service and user delegation. An account SAS can be used with any type of storage. A service SAS can be used with blob and file storage, whle a user delegation SAS can be used with blob and ADLS2 storage.
To create an account SAS, call the
get_account_sas() method. This has the following signature:
To create a service SAS, call the
get_service_sas() method, which has the following signature:
To create a user delegation SAS, you must first create a user delegation key. This takes the place of the account's access key in generating the SAS. The
get_user_delegation_key() method has the following signature:
Once you have a user delegation key, you can use it to obtain a user delegation sas. The
get_user_delegation_sas() method has the following signature:
(Note that the
key argument for this method is the user delegation key, not the account key.)
To invalidate all user delegation keys, as well as the SAS's generated with them, call the
revoke_user_delegation_keys() method. This has the following signature:
See the Shared access signatures page for more information about this topic.
The client-side interaction with a storage account is via an endpoint. A storage account can have several endpoints, one for each type of storage supported: blob, file, queue and table.
The client-side interface in AzureStor is implemented using S3 classes. This is for consistency with other data access packages in R, which mostly use S3. It also emphasises the distinction between Resource Manager (which is for interacting with the storage account itself) and the client (which is for accessing files and data stored in the account).
To create a storage endpoint independently of Resource Manager (for example if you are a user without admin or owner access to the account), use the blob_endpoint or file_endpoint functions.
If a storage endpoint is created without an access key and SAS, only public (anonymous) access is possible.
blob_endpoint, file_endpoint, create_storage_account, get_storage_account, delete_storage_account, Date, POSIXt
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
## Not run: # recommended way of retrieving a resource: via a resource group object stor <- resgroup$get_storage_account("mystorage") # list account access keys stor$list_keys() # regenerate a key stor$regen_key(1) # storage endpoints stor$get_blob_endpoint() stor$get_file_endpoint() ## End(Not run)
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.