On UWP app, downloading a blob results in a 403 error - Failed to authenticate the request

[michaeldaw]

I'm attempting to download a blob (DownloadTextAsync()) in a Universal Windows Platform application. It seems that the attempt will succeed once, and then fail on subsequent attempts. An exception is thrown with the following details:

<?xml version="1.0" encoding="utf-16"?>
<!--An exception has occurred. For more information please deserialize this message via RequestResult.TranslateFromExceptionMessage.-->
<RequestResult>
  <HTTPStatusCode>403</HTTPStatusCode>
  <HttpStatusMessage>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.</HttpStatusMessage>
  <TargetLocation>Primary</TargetLocation>
  <ServiceRequestID>e119a40e-0001-00c8-0258-e4802a000000</ServiceRequestID>
  <ContentMd5 />
  <Etag />
  <RequestDate>Mon, 31 Aug 2015 19:49:34 GMT</RequestDate>
  <StartTime>Tue, 01 Sep 2015 01:49:34 GMT</StartTime>
  <EndTime>Tue, 01 Sep 2015 01:49:34 GMT</EndTime>
  <Error>
    <Code>AuthenticationFailed</Code>
    <Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:e119a40e-0001-00c8-0258-e4802a000000
Time:2015-09-01T01:49:33.9890749Z</Message>
    <AuthenticationErrorDetail>The MAC signature found in the HTTP request 'vqyaHrAZ8iMdgUVuuDGTq4H6MwzXyI5h5DhcNAxdGEA=' is not the same as any computed signature. Server used following string to sign: 'GET

Tue, 01 Sep 2015 01:42:45 GMT

"0x8D2B26EA2474D14"

x-ms-client-request-id:ca191a47-ed20-4407-8c2a-bfbbccbd2858
x-ms-date:Tue, 01 Sep 2015 01:49:34 GMT
x-ms-version:2015-02-21
/[mystorageaccount]/newcontainer/newFile.json'.</AuthenticationErrorDetail>
  </Error>
  <ExceptionInfo>
    <Type>StorageException</Type>
    <HResult>-2147467259</HResult>
    <Message>Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.</Message>
    <Source>Microsoft.WindowsAzure.Storage</Source>
    <StackTrace>   at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.&lt;ExecuteAsyncInternal&gt;d__6`1.MoveNext()</StackTrace>
  </ExceptionInfo>
</RequestResult>

Looking around the internet, it seems a popular solution to seeing this error when using the Storage Client is to ensure that the time on your computer is correct, which I have done. Additionally, I've used the exact same code in a normal Console Application and it works as expected every time.

This is the code I'm using:

var connectionString = [myconnectionstring];
var storageAccount = CloudStorageAccount.Parse(connectionString);
var blobClient = storageAccount.CreateCloudBlobClient();
var container = blobClient.GetContainerReference("newcontainer");
var blob = container.GetBlockBlobReference("newFile.json");
var text = await blob.DownloadTextAsync();

[pemari-msft]

Hi @michaeldaw, can you share your account name as well so I can take a look at the service logs? It would be best if you could email that account name to ascl [at] microsoft dot com.

The fact that it's successful once before failing indicates to me that there might be something larger at play.

Thanks!

[pemari-msft]

Also, is this reproducible? If you could also repro it and send a very recent stack trace as well as your account name to that address we'll have the most information while debugging.

[michaeldaw]

Hi @pemari-msft . I sent an email to the address you specified. It contains the information you requested. I hope it helps. Let me know if I can do anything else.

[pemari-msft]

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 and the extra information.

[michaeldaw]

Understood. Thanks for looking in to this, Peter.

[guardrex]

Just a reminder: The Azure Storage REST API could be used as a workaround.

[michaeldaw]

@GuardRex absolutely. Also, I've found the Table and Queues to be working fine under UWP, though they probably shouldn't be used in production until officially supported.

[pemari-msft]

Hey @michaeldaw -- would you mind trying again with version 6.0.0? I added a workaround that may help you in this case.

[michaeldaw]

Hi @pemari-msft -- I tried 6.0.0 and and 6.0.1-preview. I'm afraid I got the same result as before. It worked the first time I tried, but threw the "failed to authenticate the request" exception on subsequent attempts. The exception message is the same as in my original post. Again, this is only true on UWP (Windows 10) apps. If there something else you'd like me to try, please let me know.

[SWilkov]

Hello @pemari-msft I'm seeing the exact same problem as this when downloading blobs in UWP. Was there any fix for this? Thanks in advance. Heres my question on Stackoverflow

[pemari-msft]

You can try our 6.1.1-preview release which has some more changes that might help this issue. We're currently in discussions with the UWP team to get to the bottom of why this issue has occurred. Please feel free to try out our latest bits to see if you reach any blockers, although we won't support officially until we do further testing. Thanks!

[krishnakanike]

<403> : Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. it was working till few days ago. now its not..

[pemari-msft]

@krishnakanike, are you using a UWP app? If not, please create a new issue. If you are, please understand that this is not a bug in our library (if you're referring to the caching behavior). However, this is really not temporally related -- if you have something that was working but now isn't, it's more likely an issue with how you're using Authorization/Authentication. Please open a new issue and we'll get to the bottom of it.

Thanks.

[krishnakanike]

@pemari-msft - Thank you for prompt reply. I am using Microsoft Azure Storage command line and cmd line for AzCopy. I get the same above 403 Error. However, when i use Azure Storage explorer GUI, copy works. Not sure, what is the problem with command line. Its really sometimes frustrating when we see things dont work as they are supposed to be, and upon asking for help in forums get an above reply(to open a bug/issue). How & where do i open an issue related to cli ?

[mirobers]

@krishnakanike You should take a look here for AzCopy: https://azure.microsoft.com/en-us/documentation/articles/storage-use-azcopy/

[ghost]

I can confirm that I had UWP code on IoT-Core that worked, and upon updating the NuGet to WindowsAzure.Storage 6.2.0. I get the titled access errors as well. I first expected async issues until I saw this. Here is a stack trace:

Microsoft.WindowsAzure.Storage.WrappedStorageException occurred Message: Exception thrown: 'Microsoft.WindowsAzure.Storage.WrappedStorageException' in Microsoft.WindowsAzure.Storage.dll Additional information: <?xml version="1.0" encoding="utf-16"?>

403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. Primary a4a9734e-0002-0042-3ecb-445126000000 Fri, 01 Jan 2016 19:34:06 GMT Fri, 01 Jan 2016 18:34:04 GMT Fri, 01 Jan 2016 18:35:18 GMT AuthenticationFailed Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:a4a9734e-0002-0042-3ecb-445126000000 Time:2016-01-01T19:36:02.4532893Z StorageException -2147467259 Cannot access a closed Stream. ObjectDisposedException -2146232798 Cannot access a closed Stream. mscorlib at System.IO.__Error.StreamIsClosed() at System.IO.BufferedStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken) at System.Net.Http.DelegatingStream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, CancellationToken cancellationToken) at Microsoft.WindowsAzure.Storage.Core.Util.StreamExtensions.<WriteToAsync>d__3`1.MoveNext() --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task) at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.<ExecuteAsyncInternal>d__c`1.MoveNext()

[nvtamcntt]

Hi everyone : I had same a bug relate to "com.microsoft.windowsazure.services.core.storage.StorageException: Server failed to authenticate the request" I don't know why it error . any one help me..
my code :

CloudStorageAccount account; CloudBlobClient serviceClient; CloudBlobContainer container; CloudBlockBlob blob;

final String bucketName = PropertyReader.getValue("aws.properties", bucket);

account = CloudStorageAccount.parse(storageConnectionString); serviceClient = account.createCloudBlobClient(); // Container name must be lower case. container = serviceClient.getContainerReference(bucketName); container.createIfNotExist();

// Set anonymous access on the container. BlobContainerPermissions containerPermissions; containerPermissions = new BlobContainerPermissions(); containerPermissions.setPublicAccess(BlobContainerPublicAccessType.CONTAINER); container.uploadPermissions(containerPermissions);

// Upload an image file. blob = container.getBlockBlobReference(imageName); blob.upload(imageStream, imageArray.length);

==> Catch exception from line container.createIfNotExist();

Refer giihub : http://stackoverflow.com/questions/34527852/com-microsoft-windowsazure-services-core-storage-storageexception-server-failed?noredirect=1#comment56799023_34527852

[pemari-msft]

Hi all -- not all 403s will be related to this issue. @nvtamcntt, this isn't even the correct language or platform to be related.

@hubert-associates, this looks like it could be similar. Can you provide a recent request id (preferably in the last 24 hours) of the issue so I can confirm? However, there are two separate exceptions you posted. I don't see how they both could be happening so perhaps you could clarify what call produces these errors? For instance, could you give a small repro snippet so I can understand your scenario?

[ghost]

Thanks. This is definitely the "UWP unsupported" problem (C#, Windows 10 IoT-Core ARM RaspberryPi): I start with a fresh IoT-core deployment, and downloads (table, blob) via the azure storage client work a few times and then start bringing 403 errors. Here is a trace from yesterday, I have now re-deployed from scratch and can work again for a few hours until it punts. I hat to rip out all the code, but must if there is no workaround (e.g. which cache to regularly delete) or prognosis.

GetAndStoreConfigFromCloud MAC=b8-27-eb-27-b4-e4 'backgroundTaskHost.exe' (Win32): Loaded 'C:\Windows\System32\CryptoWinRT.dll'. Skipped loading symbols. Module is native, and native debugging is currently disabled. Exception thrown: 'Microsoft.WindowsAzure.Storage.StorageException' in Microsoft.WindowsAzure.Storage.dll Exception thrown: 'System.NotSupportedException' in System.IO.dll Exception thrown: 'System.NotSupportedException' in System.Private.CoreLib.dll Exception thrown: 'Microsoft.WindowsAzure.Storage.WrappedStorageException' in Microsoft.WindowsAzure.Storage.dll Exception thrown: 'Microsoft.WindowsAzure.Storage.WrappedStorageException' in System.Private.CoreLib.dll Exception thrown: 'Microsoft.WindowsAzure.Storage.WrappedStorageException' in System.Private.CoreLib.dll GetAndStoreConfigFromCloud Exc=Microsoft.WindowsAzure.Storage.WrappedStorageException: <?xml version="1.0" encoding="utf-16"?>

403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. Primary da12c8e6-0002-000e-3f1a-4e9639000000 Wed, 13 Jan 2016 15:29:16 GMT Wed, 13 Jan 2016 14:29:15 GMT Wed, 13 Jan 2016 14:29:21 GMT AuthenticationFailed Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:da12c8e6-0002-000e-3f1a-4e9639000000 Time:2016-01-13T15:52:19.1114255Z StorageException -2146233088 Stream does not support reading. NotSupportedException -2146233067 Stream does not support reading. <unknown> at System.IO.Stream.ReadAsync(Byte[] buffer, Int32 offset, Int32 count, Threading.CancellationToken cancellationToken) at SharedLibrary!<BaseAddress>+0xe376b1 at SharedLibrary!<BaseAddress>+0x74c5d5 --- End of stack trace from previous location where exception was thrown --- at SharedLibrary!<BaseAddress>+0x4f60e5 at SharedLibrary!<BaseAddress>+0x4f65f1 at SharedLibrary!<BaseAddress>+0x4f650d at SharedLibrary!<BaseAddress>+0x4f6471 at SharedLibrary!<BaseAddress>+0x81dff7 at SharedLibrary!<BaseAddress>+0x75430f ---> Microsoft.WindowsAzure.Storage.StorageException: Stream does not support reading. ---> System.NotSupportedException: Stream does not support reading.

[pemari-msft]

I completely understand. Like I said, this is a bug in WinINet, the networking layer of UWP. There is no ability to 'clear the cache', manually or via config or otherwise. They are working on the fix.

However, our logging indicates that this request failed because the date header was too old for the request (ie the request was signed but not sent within a few minute delta of the signing). Please take a look at your exception output:

`Wed, 13 Jan 2016 15:29:16 GMT Wed, 13 Jan 2016 14:29:15 GMT Wed, 13 Jan 2016 14:29:21 GMT

AuthenticationFailed Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature. RequestId:da12c8e6-0002-000e-3f1a-4e9639000000 Time:2016-01-13T15:52:19.1114255Z`

The machine thinks the time is 14:29 GMT. The request thinks it is happening at 15:29. Our logs show the request occurs at 2016-01-13T15:52:19.1114255Z. Can you please check the machine to make sure there's no clock skew?

I agree this could be related and that it's frustrating, but it would be good to isolate any other problems. Are there any other steps involved in the repro? Is it consistent? A fiddler trace sent to ascl@microsoft.com would be a source of truth for us here.

[ghost]

Many thanks for a response! OK, the displayed time and zone on the IoT-core on RPi (latest) is correct in my time zone (Germany). So it looks like the Azure Storage Client may be using UTC/GMT time for its header construction!? That would explain a lot. I use the REST API for the Azure Service Bus without any problem and use the system time to construct the security token and header. Thus, I am pretty sure that the mistake is not in my code and not in the IoT-Core RPi. Would it help if I set my clock/zone to GMT you think -- as a workaround of course? Worth a try.

I love fiddler, but I don't think it is available on IoT-Core RPi yet? Would be great if it were. Any ideas? Since this is my current show stopper, I have started migrating all of my Blob/Table stuff to REST -- I would prefer to stick with the lib, if I could have some indication of a potential fix time-window.

[ghost]

@pemari-msft We are still waiting for a fix for this bug. We have tried everything including setting UTC time on our device and using the direct REST API. No workarounds found yet. Can we get any specific information on a fix date or a patch since this is a disappointing show stopper. IoT without the "Io" ;-)

[ghost]

@GuardRex The REST API hits the same bug. This has been confirmed after we converted all of our code to use the REST API. The exceptions arise at the very same place in the UWP code, regardless.

[drew-hoffman]

I'm running into (what I believe is) this same problem with the local development storage emulator. Am I right to assume that this issue effects the storage emulator too?

[mirobers]

@hubert-associates Are you seeing the clock skew issue? Please compare the time header sent on the request to the time header received on the response; if they are far off then this is the issue.

@greenwizard88 It makes sense that it would affect requests to the emulator, as it is a UWP issue.

[ghost]

Thanks. The clock skew issue has also been observed. We tried to circumvent this by using GMT/UTC worldwide and synchronizing clocks regularly. Didn't work. As noted above and elsewhere, this is a confirmed bug in UWP (more diplomatically: a non-supported issue) with the REST API to azure storage et. al., and thus also appears in the azure client libraries. All of our considerable attempts have only succeeded in sometimes delaying the crash in the UWP-IoT-core code. We still await a fix or a real workaround.

[opoyry]

This might be totally off topic but http://blog.thomaslebrun.net/2015/11/create-your-own-spying-camera-system-with-windows-azure-and-a-uwp-application has this:

    var serviceProperties = await blobClient.GetServicePropertiesAsync();
    serviceProperties.Cors.CorsRules.Clear();
    serviceProperties.Cors.CorsRules.Add(new CorsRule
    {
        AllowedHeaders = new List<string> { "*" },
        AllowedMethods = CorsHttpMethods.Get | CorsHttpMethods.Head,
        AllowedOrigins = new List<string> { "*" },
        ExposedHeaders = new List<string> { "*" }
    });
    await blobClient.SetServicePropertiesAsync(serviceProperties);

[ghost]

Thanks. He is not using it on the ARM platform, looks like a long shot, but worth a try! I'll try anything at the moment -- desperado ;-)

[dchinn]

any movement on this? We've just run into the same error message. why did it suddenly stop working?

[ghost]

Still no new release of iot-core UWP ARM as far as I know. What works for us currently are Azure blobs with the azure client lib on UWP iot-core but not the table or svc-bus client libs nor the REST for those. Also, the Azure iot-hub stuff works fine. This may be a subtle strategy to get us onto the (more expensive) iot-hub @ iot-core instead of the classic azure APIs, just guessing though...

[pemari-msft]

Hi All, in the latest version of UWP I believe this issue was fixed. We are no longer able to repro. Please let us know if you find any further issues!