I have created 2 queues:
- For the first queue, I wrote a program and I have used StorageClinet
- For the other queue, I played around with "Azure Storage Explorer" and NEW queue button
After queues creation I have performed ... Fiddler 2 --> Composer --> GET http://127.0.0.1:10001/devstoreaccount1?comp=list <EXECUTE>
I was hopping for a response containing a list of my two recently created queues.
However there was a "404 The Specified resource does not exist" error message. Is there any way to fix the 404-problem and list my queues ?
Hi - thanks for the question!
The reason this is failing is because the request is not authenticated. Even when talking to developer storage, all requests (except those for blobs which have their access set to "Public") must be authenticated.
You can use CloudQueueClient.ListQueues() method in storage client to get a list of queues, or you can learn about how to authenticate your requests here: http://msdn.microsoft.com/en-us/library/dd179428.aspx. The Storage Emulator authentication information can be found here: http://msdn.microsoft.com/en-us/library/gg432983.aspx, though I presume you've already found taht since you're successfully creating queues.
Hope that helps, let us know if we can help with anything else.
Did you provide Authorization Header and x-ms-date in the request header? Little odd to see 404 instead of 403 though, but please try providing request headers and see.
I have repeated my experiment including headers this time:
x-ms-date: Fri, 02 Mar 2012 22:15:16 GMT
Authorization: SharedKeyLite devstoreaccount1:Eby8vdM02xNOcqFlqUwJPLlmEtlCDXJ1OUzFT50uSRZ6IFsuFq2UVErCz4I6tq/K1SZFPTOtr/KBHBeksoGMGw==
The system response this time is "403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature".
I have used the predefined values for Local-Storage-Development but nothing happened.
Thank you for the support
Hi - sorry for the difficulties. The authorization header should not include the actual shared key itself. Instead, you construct a "String to Sign", composed of several things like the content-md5, content-type, etc. Then, when it's constructed, you encode the string by using the HMAC-SHA256 algorithm over the UTF-8 encoded string. Please see the "Blob and Queue Service (Shared Key Lite Authentication)" section of the "Authentication Schemes" page for more information on how to generate the correct headers. Also, please note that the security best practice is to use Shared Key authentication, not Shared Key Lite. This is discussed in the section "Blob and Queue Service (Shared Key Authentication)". The principle is the same, you just include more in the string to sign.
Please let us know if you have further questions.
- 已标记为答案 karpathosWinds 2012年3月4日 7:09
Finally made it to communicate with Local Azure Queue Service using REST requests. The part of preparing a correct string to sign is rather tricky.
Now continuing with code elaboration handling more requests with a message body also.
Thank you, Jeff