The text states:
is the SHA-256 hash computed over the resource URI (scope as described in the previous section) and the string representation of the token expiry instant, separated by CRLF
Then the pseudo-code uses simply 'n':
SHA-256('https://<yournamespace>.servicebus.windows.net/'+'\n'+ 1438205742)
Can you make these consistent and correct?
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@dlstucki Thanks for bringing this to our attention. Your feedback has been shared with the content owner for further review.
It is just \n according to https://github.com/Azure/azure-sdk-for-net/blob/4bab05144ce647cc9e704d46d3763de5f9681ee0/sdk/servicebus/Microsoft.Azure.ServiceBus/src/Primitives/SharedAccessSignatureTokenProvider.cs#L143.
The SHA-256 pseudo-code is misleading. The signing is done with HMACSHA256 using the SAS policy's primary or seconday keys as input key. (https://github.com/Azure/azure-sdk-for-net/blob/4bab05144ce647cc9e704d46d3763de5f9681ee0/sdk/servicebus/Microsoft.Azure.ServiceBus/src/Primitives/SharedAccessSignatureTokenProvider.cs#L167)
It wasn't hard for me to figure out which was correct. The point of this issue is to have the documentation fixed to be consistent and point users at the right format. Read the initial description. (I'll update title to clarify).
I just wanted to point out the source and also that the pseudo-code is at best misleading (it doesn't mention they key at all), and also I wanted to get some attention on this issue, which has been open for 11 months now.
n is a bit unclear. However, "SHA-256('https://
Also a real example should be added, n and HMACSHA256 and url encoding stuff may make much sense with an example and save a lot of time for us.
Most helpful comment
I just wanted to point out the source and also that the pseudo-code is at best misleading (it doesn't mention they key at all), and also I wanted to get some attention on this issue, which has been open for 11 months now.