[BidirectionChat] issues and clarifications

[rockgecko-development]

I worked through the BidirectionChat sample and encountered a few errors and omissions, so I thought I'd list them for the next person:

1. The header x-ms-signalr-user-id is never sent from the frontend. The function

   AzureSignalR-samples/samples/BidirectionChat/csharp/content/index.html

   Lines 173 to 178 in bb7652a

   	function getAxiosConfig() {
   	const config = {
   	headers: {
   	'x-ms-signalr-user-id': data.username,
   	'Authorization': 'Bearer ' + generateAccessToken(data.username)
   	}

   
   is never called.
   The signalr js lib has the ability to include headers in the setup, although that feature was added in a later version to what this demo is currently using.
   Delete getAxiosConfig, update the signalr client library, and use:

const connection = new signalR.HubConnectionBuilder()
          .withUrl(apiBaseUrl + '/api', {
              headers: { 'x-ms-signalr-user-id': data.username },
          accessTokenFactory: () => {
            return generateAccessToken(data.username)
          }
        })

2. Because the header wasn't passed, the negotiate function

   AzureSignalR-samples/samples/BidirectionChat/csharp/Function.cs

   Lines 32 to 34 in bb7652a

   	public SignalRConnectionInfo Negotiate([HttpTrigger(AuthorizationLevel.Anonymous)]HttpRequest req)
   	{
   	return Negotiate(req.Headers["x-ms-signalr-user-id"], GetClaims(req.Headers["Authorization"]));

   was passing empty string for the userId param, and yet somehow, a username was still being populated. I believe this was happening via the http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier claim. Passing null, or, with point 1 fixed, passing a username, seemed to cause a

Invocation failed, status code 500

error when calling any hub method after negotiating.
Updating the signalr-service-extension C# library version to latest fixed that issue

3. It took me some time to understand how the jwt was used in this sample. One is created in the frontend and signed with the key myfunctionauthtest, no checking is performed on the backend, and the key is not shared. For a real-life app I wanted to use an Active Directory token containing multiple groups claims - where I ran into this issue: Multiple jwt claims of the same type not supported? Azure/azure-functions-signalrservice-extension#260. That aside, I believe the correct workflow is to verify my token in the Negotiate function, then add the claims I want to refer to later via return Negotiate(name, claims). These claims are sent to the signalr service via a new jwt signed with the signalr access key
4. It also took me a while to understand that the hub methods are called by the azure signalr service, and therefore won't work locally. There's a signalr serverless emulator available here: https://github.com/Azure/azure-signalr/blob/dev/docs/emulator.md for local development. Perhaps it could be mentioned in this documentation?
5. I only just found out that there's another version of this sample here: https://github.com/Azure/azure-functions-signalrservice-extension/tree/master/samples/bidirectional-chat , which fixes 1 and 2.