Azure Storage: 403 Server failed to authenticate the request
Asked Answered
D

2

11

I've search here and in Google but I can't find a solution.

With my C# code I want to read a file from Azure Storage Blob. The code (only 6 line) works very well in another project (Windows 8.1 Universal App) but not in my new Windows 10 UWP App.

This is my code:

CloudStorageAccount storageAccount = CloudStorageAccount.Parse(azureConnectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("container-name");

CloudBlob b1 = container.GetBlobReference("27.76914.json");
StorageFile file = await ApplicationData.Current.LocalFolder.CreateFileAsync("stefano1.json", CreationCollisionOption.ReplaceExisting);
await b1.DownloadToFileAsync(file);

The Exception:

Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

Using Fiddler4 I found this error on message 403:

The MAC signature found in the HTTP request 'R2t9hKsyXf470HF2LNP8T+M2nci0ddE/ojQ0r4UVjJQ=' is not the same as any computed signature

My attempts:

  1. The application works the first time (file downloaded). The second time I get the Exception.
  2. If I change the requested file name: the application works the first time (file downloaded). The second time I get the Exception.
  3. The next day I get immediately the same exception (at first run)
  4. Also if I delete bin and obj folders I get the error
  5. If I create another application and try to download the same file (same as point 1), it works the first time, but not the second.
  6. In a Console Application all works well.

This is the Fiddler4 Raw Request (where ***** is my Azure Storage Account Name):

GET https://*****.blob.core.windows.net/container-name/27.76914.json HTTP/1.1
x-ms-client-request-id: accee7e7-646d-417a-b734-1591cbc16a8d
x-ms-date: Thu, 03 Sep 2015 06:31:37 GMT
x-ms-version: 2015-02-21
User-Agent: WA-Storage/5.0.2 (Windows Runtime)
Authorization: SharedKey *****:R2t9hKsyXf470HF2LNP8T+M2nci0ddE/ojQ0r4UVjJQ=
Host: *****.blob.core.windows.net
If-Modified-Since: Sun, 30 Aug 2015 18:52:41 GMT
If-None-Match: "0x8D2B16C2ED82C4A"
Connection: Keep-Alive

Thank you!

Debbiedebbra answered 2/9, 2015 at 22:4 Comment(4)
Could you please post the raw request as you see it in Fiddler.Cormick
Did you get any solution on this issue as I'm having the same problem in UWP app?Toxicant
No, I'm still waiting for a solution. My temporary workaround is a web service bridge between my UWP App and Azure Blob (because I'm in beta). So my UWP App use Azure Blob Storage API for upload and list blobs, but use my custom web service to download them.Debbiedebbra
Yes, this is the predicament IoT-core/UWP users are in at the moment. You can use (at your own risk) the storage client lib for uploads but have to add REST APIs to the services for download until the client lib is supported. See #34595257Pilotage
Y
6

This was also reported on our GitHub page here: https://github.com/Azure/azure-storage-net/issues/171

Our leading theory is that a caching proxy might be in between the client and the server affecting your requests.

We're still investigating and will let you know.

Yancy answered 2/9, 2015 at 22:54 Comment(6)
Overall, we don't actually support Windows 10 Universal apps yet which is why we don't have much information yet. :)Yancy
Thank you Peter, I had not seen that page. I hope you will find a workaround.Debbiedebbra
Okay, so I can confirm now that there’s some sort of caching mechanism at play in the UWP code that is happening even when the connection is using HTTPS. We’ll have to investigate more but this is probably going to have to require some sort of code change for us – unfortunately, this will likely mean this is going to fall under the umbrella of “UWP is not currently supported” in the immediate term. Hopefully we can determine the issue and come up with a fix for an upcoming release. Thanks again for the bug report.Yancy
Hi @PeterMarino-MSFT is there any update on this problem with UWP as I'm getting exact same error. thanksToxicant
Looks like I've run into the same problem #34595257 Funny thing is, that it was working for a while, and then just quit: tell me which cache it is :-)! ... so I can delete it and make it work again. No, seriously, I'd be very appreciative of a fix or definitive answer here. If not fixable, then I'll have to rip a lot of storage lib code out...Pilotage
It's not our cache. It's a bug in the UWP code. Can you tell us which version of our library you're using?Yancy
F
0

I've had a similar issue (in Java) trying to access blobs from local machine. Trying to download a blob would work one out of two times, trying to get an InputStream never worked. In both cases the error was the same as yours.

My code always worked from a VM in the cloud. The issue was fixed when I've changed the default protocol from HTTP to HTTPS. When constructing your CloudStorageAccount, there is a constructor that allows you to specify the default protocol. It's also available for C# (here)

Also for the record, AZCopy will fail for a source with HTTP, with similar error. You might give it a try.

Fleshly answered 26/1, 2016 at 10:12 Comment(1)
That's a little different, but thanks for the suggestion! HTTPS is always recommended.Yancy

© 2022 - 2024 — McMap. All rights reserved.