2
votes

I am confused about SignalR, specifically when using the Azure SignalR Service and then even more so when thinking about the server-less implementation using Azure Functions.

I have a web app and an Azure Function app, which has a negotiation function implemented. The JavaScript on the client is successfully negotiating and able to connect to the Azure SignalR Service, so far so good.

Side question: Is the only thing that stops any old person connecting and getting a token the CORS setting? Is this secure enough on its own?

After this is where I get confused. I now have a Azure SignalR Service and an Azure Function app, what use does the Function App serve after the client connection to the Azure SignalR Service has been established?

In terms of client interaction I need to do things like join a group and broadcast to said group (from JavaScript on the client), I assume those would be two additional functions (Http triggers) on the function app?

Assuming I am correct on the above, how do I stop anyone from calling the 'broadcast' function via the function apps http endpoint? At least locally I am able to call it from Postman without providing any information received in the initial negotiate response.

I also need to push messages to groups from backend code (.net standard), is this done by a call to the function app or straight to the Azure SignalR Service?

Thanks in advance.

1
After a bit more reading it seems the answer might be to use the RestAPI for everything other than clients sending messages?blawford

1 Answers

1
votes

That's a great question!
I was wondering the same thing when I've started to lean towards a completely serverless approach.

Is the only thing that stops any old person connecting and getting a token the CORS setting? Is this secure enough on its own?

It sure seems this way when you start, but the answer is no.
You can authenticate your functions. Either with the built in providers, or you can authenticate yourself, by creating your own custom binding for checking the token that is passed via the header.

In terms of client interaction I need to do things like join a group and broadcast to said group (from JavaScript on the client), I assume those would be two additional functions (Http triggers) on the function app?

You are assuming correctly. If you want to go completely serverless, this is the way to go. You can authenticate the functions the same way as you authenticate your SignalR negotiating function and you will have a secure endpoint which will call the SignalR service for you.

I also need to push messages to groups from backend code (.net standard), is this done by a call to the function app or straight to the Azure SignalR Service?

This one has no right answer. That really depends on your specific architecture. Without more context, it would be hard/wrong to try to answer this question.

Oh, and if you are going serverless with SignalR, I really hope you are utilizing their bindings. :)