Download BLOB from *private* container to Windows Phone

Question

It's not an option for me to expose my container to the world.

The Microsoft.WindowsAzure toolkit stuff doesn't run on Windows Phone so I can't do:

var client = new Microsoft.WindowsAzure.StorageClient.CloudBlobClient("url",
	new Microsoft.WindowsAzure.StorageCredentialsAccountAndKey("name", "key"));
var container = client.GetContainerReference(AZURE_CONTAINER_NAME);
var blob = container.GetBlobReference(anid);
using (var isoStream = IsolatedStorageFile.GetUserStoreForApplication().OpenFile("filename", FileMode.Create))
{
	blob.DownloadToStream(isoStream);
}

So how are we supposed to do this on Windows Phone? From what I can find in the Azure toolkit for WP7, there's Upload facilities all day long, but *nothing* to facilitate downloading BLOBs from Azure.

---

Twitter: @bc3tech

Answer 1

I haven't done any work with Windows Phone and Azure but if you don't want to make your container public, what you could do is create a SAS URL for your blob and then download the blob to your phone using that SAS URL. I believe you don't even need to use Azure SDK for that. Simply using WebClient should work.

You may find this link useful: http://msdn.microsoft.com/en-us/library/windowsazure/hh508996

Hope this helps.

Answer 2

Using the Phone.Storage package from NuGet (published by Microsoft), I have the following code:

var container = CloudStorageContext.Current.Resolver.CreateCloudBlobClient().GetContainerReference("appname");
container.GetSharedAccessSignature(containerResponse =>

which kicks out a System.NotSupportedException every time:

"This operation is not supported in this implementation"

---

Twitter: @bc3tech

Answer 3

So every user of your phone app will have their own Windows Azure storage account? (How else would they know the key for the account?)

Answer 4

So every user of your phone app will have their own Windows Azure storage account? (How else would they know the key for the account?)

um... no. that's not how it works.

---

Twitter: @bc3tech

Answer 5

In order to generate SAS URL you would need to have access to storage account name and key. What you could do is generate a SAS URL for your blob container/blob outside of your application and use those URLs in your application.

Answer 6

In order to generate SAS URL you would need to have access to storage account name and key. What you could do is generate a SAS URL for your blob container/blob outside of your application and use those URLs in your application.

Right but SAS URLs change based on timestamps and whatnot, so every time I want to d/l a BLOB I'd have to make some sort of call to a web service from my app to gen the SAS URL, get that back, then use it in my BLOB request - that's a round-trip I'd rather not make. This further prompts the question: why do I have to be outside my phone app to gen a SAS URL? To me it appears to be functionality that is shown by the Phone.Storage package (GetSharedAccessSignature) but not implemented (throws exception when used).

If using SAS URLs is the only way to do what I need to do here, then my feeling is that this unimplemented-yet-exposed functionality is a "bug" that fell thru the cracks when the Phone.Storage package was released, since you can do it in the Windows (proper) Azure SDK, and I'm hoping I can somehow get the authors to release an update.

---

Twitter: @bc3tech

Answer 7

I had a demo on this scenario from earlier this year - I'll try to pull it up and share some code.  But until then,let me try to provide an answer.

The reason for the difference between how the Phone.Storage libraries work and the Windows Azure SDK is related to the storage account credentials.  With the Azure SDK, the credentials are known - in your .csfg file for example and trust, and thus the SDK makes a REST API call to Windows Azure storage, providing your credentials, to get the SAS requested.  We wouldn't want the storage account credentials on the phone.  Therefore, with the Phone.Storage library a proxy service is needed to make a request to a trusted source (e.g. web service running someplace else -like a web role or any other hosting provider).  The proxy then initiates the SAS request to Windows Azure storage and returns the necessary information.

Given the need to request a SAS from Windows Azure storage, I don't think you'll ever get away from having to make at least one initial trip.  It works that way with the Azure SDK too - it's just kind of hidden from you (think you would see that network traffic if you watch for it via Fiddler).

As for why GetSharedAccessSignature throws an exception when using the Phone.Storage library, I would assume (not one to speak for the authors), that this was done to try to keep as much parity between the Phone.Storage library and the Azure SDK.  This may allow for the future option to change the function's implementation to not need the request to a proxy service.

Make sense?  Help?

Answer 8

Thanks Mike, I see where you're coming from but am still a bit confused on the "we wouldn't want credentials stored on the phone" part.

Presently I can list, upload, change BLOBs in Azure w/ the Phone.Storage SDK w/o issue, and to do so I have to put code like the following in place:

var client = new Microsoft.WindowsAzure.StorageClient.CloudBlobClient("url",
	new Microsoft.WindowsAzure.StorageCredentialsAccountAndKey("name", "key"));

So I'm not sure what you mean by the creds aren't on the phone... they have to be for me to even create the client to do BLOB uploading at all

---

Twitter: @bc3tech