-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secondary Authentication fails in Production style URL #2208
Comments
Snippet which causes the regression: Now, this works fine for non-production URLs like - 127.0.0.1:10000/devaccount-secondary/testcontainer. As there is a secondary suffix in the authentication path - /devaccount-secondary/testcontainer. So this path gets transformed to /devaccount/testcontainer Now, let's take a look at production URL trying to access a secondary storage, devaccount-secondary.sample.com/testcontainer. The authentication path looks like this - /testcontainer. |
Thanks for finding and investigation of this issue! Azurite welcome contribution! |
I have reviewed your PR, and raised a comment for change log and test case. |
* Fixes issue #2208 * Code review comments * Code review comments * Code review comments * Code review comments * Code review comments * Code cleanup * Tests fail on local dev - so using Azure devops to test if these are passing there * Testing changes in Azure Devops * Canonicalized Resource string bug fixed * Fixed bug in createStringToSignForSharedKeyLite routine * Fixes bug in createStringToSignForSharedKeyLite * Clean up and documentation
Which service(blob, file, queue, table) does this issue concern?
Blob, queue, table, all of them fail.
Which version of the Azurite was used?
V3.26.0
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
NuGet - custom built
What's the Node.js version?
V18 LTS
What problem was encountered?
In Authentication string to sign, Authentication Path is not formed correctly when using Production style URL for secondary requests.
Steps to reproduce the issue?
Take any storage client, use production style URL with -secondary suffix for secondary read operation on Azurite.
You can observe the string to sign is malformed for these requests.
Have you found a mitigation/solution?
Yes, I have fixed the error. Until it gets merged use non-production style URL for secondary requests.
The text was updated successfully, but these errors were encountered: