Closed tanyunshi closed 3 months ago
@tanyunshi
From the debug log:
The difference is the "Content-Type" "application/x-www-form-urlencoded" is your request is missed from your stringToSign. Per this doc, StringTosign for Queue service contains "Content-Type".
It looks the failure is caused by the StringTosign generated from your client missed "Content-Type". Would you please check the same program works on product Azure server or not? Is not work, this should be client issue. If works, please inform us and we will continue the investigation on it.
Hello @blueww
Thank you for your feedback.
The same code works well with Azure Storage account (Set
AzureWebJobsStorage
to DefaultEndpointsProtocol=https;AccountName=serious_account_name;AccountKey=secret==;EndpointSuffix=core.windows.net
in the code).
@tanyunshi
I have validated send a putmessge request to product Azure server with Content-Type: application/xml
, and see the stringToSign need include "application/xml".
So per my test, on product Azure server, StringToSign really will need include Content-Type.
And your stringTosign doesn't has Content-Type.
So the problem is your request has Content-Type header, but the StringTosign (used to calculate sharedkey signature) calculate from your client doesn't contain Content-Type. Please check your client, and see how it generate StringTosign on putmessgae request. Why Content-Type is not included in StringTosign? It's interesting that the same program works on product Azure. However I have checked server do need Content-Type header in StringTosign. So please check with Client team to see how they generate stringTosign.
Hello
Indeed I have the application/x-www-form-urlencoded
in my requests and I do not know why ...
Maybe it's related to some Window configuration ( proxy ? ) :( It seems to be a sad story.
I tested the same code on my personal PC with the same dependencies ( azurite, azure core tools, python etc, in the same version ). It works fine.
I introspect all the http calls and indeed there is no application/x-www-form-urlencoded
in any headers of the requests while running on my PC.
I will close the issue in a few days. Clearly not a bug from Azurite !
Hi again @blueww
I confirm that my Px proxy has somehow added a header to the requests ... By bypassing the proxy for 127.0.01, everything works well. I close this issue.
Thank you again. I cannot get this solved without your hint ! :)
Which service(blob, file, queue, table) does this issue concern?
Blob
Which version of the Azurite was used?
3.25.0, 3.29.0 at least
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
git clone and then install it with npm
What's the Node.js version?
v21.7.1
What problem was encountered?
Cannot run azure durable func tutorial (https://learn.microsoft.com/en-us/azure/azure-functions/durable/quickstart-python-vscode?tabs=windows%2Cazure-cli-set-indexing-flag&pivots=python-mode-decorators) with the following error message : Server failed to authenticate the request.Make sure the value of the Authorization header is formed correctly including the signature
Steps to reproduce the issue?
azurite --location .\azurite\ --debug .\azurite\debug6.log --loose
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
as suggested in the tutorial. I've also tried the connection stringAccountName=devstoreaccount1;AccountKey=xxx;DefaultEndpointsProtocol=http;BlobEndpoint=http://127.0.0.1:10000/devstoreaccount1;QueueEndpoint=http://127.0.0.1:10001/devstoreaccount1;TableEndpoint=http://127.0.0.1:10002/devstoreaccount1;
but I got the same error message.http://localhost:7071/api/orchestrators/hello_orchestrator
Then I got the error as shown above.Debug message
Here is the request with resp 200 ( copied from the debug log below)
Here is the request with resp 403 ( copied from the debug log below)
Have you found a mitigation/solution?
No