Access
to a BLOB is controlled by the container that it lives in. If the BLOB
lives in a public container, it’s available to the world. If the BLOB
lives in a private container, you can access it only with your private
authentication key.
Warning
Don’t distribute your private authentication key. Doing so is a surefire way to have some evildoer trash your data.
These
levels of access are a little too extreme; we need a more granular way
of controlling access to our BLOBs, namely Shared Access Signatures.
Using shared access, you can set a policy on a private container (or
BLOB), and anyone who makes a request with the correct signature can
perform the appropriate action on the BLOB (say, download the BLOB).
Although you can assign
permissions at an individual BLOB level, this is a pain to maintain.
It’s easier to maintain permissions at a container level (you can always
have a container that consists of a single BLOB).
Let’s now return to the podcast example and look at how you can control download access to one of your podcasts.
1. Setting shared access permissions on a container
Let’s say your podcasting
business has gone well and you’ve decided to start selling some of your
podcasts to the general public. In this scenario, after some rich dude
has purchased the podcast, you need to provide a way for them to
download the podcast without making it public (you obviously don’t want
to give them your owner authentication key). To achieve this, you’re
going to store your podcast (podcast03.mp3) in its own private container
(Podcast03), which isn’t available to the general public.
After your customer has
purchased the podcast, you’ll generate a Shared Access Signature that
will give that customer permission to read any BLOBs (in this case,
podcast03.mp3) in the Podcast03 container, for a period of 24 hours.
After the 24-hour period has expired, the customer will no longer be
able to download the podcast.
The first thing you need to do
is generate a shared access policy that will restrict the download
period to the next 24 hours, using the following code:
var oneDayDownloadpolicy = new SharedAccessPolicy();
oneDayDownloadpolicy.SharedAccessStartTime = DateTime.Now;
oneDayDownloadpolicy.SharedAccessExpiryTime = DateTime.Now.AddDays(1);
oneDayDownloadpolicy.Permissions = SharedAccessPermissions.Read;
As shown in the code, you can
specify both a start time and an expiry time for the policy. If you
don’t specify a start time, the value now is substituted as a default. After you’ve specified this policy, apply it to the container.
var permissions = new BlobContainerPermissions();
permissions.SharedAccessPolicies.Clear();
permissions.SharedAccessPolicies.Add("CustomerA", oneDayDownloadPolicy);
container.SetPermissions(permissions);
Finally, you can generate a URI that customers will be able to use to download the BLOB, using the following code:
string sharedAccessSignature = container.GetSharedAccessSignature(oneDayDownloadpolicy);
string uri = blob.Uri.AbsoluteUri + sharedAccessSignature;
The generated URI will look something like this:
https://chrishayuk.blob.core.windows.net/podcast03/podcast03.mp3?st=2010-01-04T12%3A08%3A00Z&se=2010-01-05T12%3A08%3A00Z&sr=b&sp=r&sig=ByfV3a1SXOXT04G4GF%2FNQo%2B9cxx4vrRE45kYxbhFhJk%3D
|
What if you want to be able to
assign permissions at a BLOB level (rather than at a container level) or
if you want to provide more than just read permissions? You can
generate Shared Access Signatures that give users permissions to write
to certain BLOBs in your container. This scenario is a little too
detailed for what we would like to show in this book, but feel free to
visit the online documentation for more details at http://msdn.microsoft.com/en-us/library/ee395415.aspx.
|
