I'm trying to use the Azure SignalR service. I've already got SignalR working locally, but when I upgrade it to use the Azure service I see the following:
Client connects to (local, .NET) hub server configured to use Azure SignalR service and is 'redirected' to our hosted SignalR service on Azure.
Client connects with https to SignalR service at https://blabla.service.signalr.net and (after a preflight request) gets a 200 response with a json payload containing list of available transports etc.
Client opens a WebSocket to the wss://blabla.service.signalr.net host. First upstream message is {"protocol":"json","version":1}.
Server responds immediately with the following response:
{"error":"An unexpected error occurred during connection handshake. NullReferenceException: Object reference not set to an instance of an object."}
What's puzzling me is that
There is no code of ours running in the SignalR service which could be causing this.
Our Hub server shows no errors related to calls from the SignalR service.
I've successfully run a chat hub on the same SignalR service using the same hub server.
How do I debug this? I can't see any activity logs on the Azure portal, and nothing is showing up locally on the hub server.
I managed to find the source of the problem by adding debugging entries to my app settings.json as follows:
"Microsoft.AspNetCore.SignalR": "Debug",
"Microsoft.AspNetCore.Http.Connections": "Debug"
This revealed that the problem was related to a call made from the SignalR service to my local hub server (via a WebSocket connection presumably)
Related
I am connecting my Signalr hub Api in different mvc5 application with javascript signalr client its perfectly works on localhost when i publish my SignalrHubAPI its gives an error negotiate 403
We are consuming WCF service from a console application with NetworkCredential(UserName && PWD) ,WSHTTPBinding.
When we call Service from Azure PAAS Service , we land into issue The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'.
The Client Config for both PAAS Consumer, Console app looks exactly same. Not sure why the error is seen only in case of PAAS Consumer.
The reason is because the PaaS service is not in the same network of your WCF service or the credentials you're using are not valid.
For example:
you're using a valid / existing credential from your company network locally:
CONTOSO\thdotnet
When publishing to Azure and trying to use the same credentials it will fail unless you're using a VPN to allow your PAAS app to call the servers running in your company's network.
I'm trying to connect my application to Azure SignalR Service. The application works fine using SignalR locally or even using Azure App Services.
services.AddSignalR();
The code above is what I had and everything works.
services.AddSignalR().AddAzureSignalR(Configuration.GetValue<string>("SignalRConnectionString"));
This is the change to be able to use Azure SignalR Service.
In the logs, I can see that the request is being forwarded to the Azure End Point.
I keep getting this error.
failed: HTTP Authentication failed; no valid credentials available
I am trying to implement the Azure service bus with help of java to receive messages from the queue but I am unable to connect to the service bus because of a proxy, I am getting a connection time exception i.e.
Microsoft.azure.servicebus.primitives.ServiceBusException: Error{condition=proton:io, description='Connection timed out: no further information', info=null}
and when I am trying it from my local network(without proxy) it is connecting to azure bus without any problem. I am using the same sample code which Microsoft has provided on GitHub i.e. QueuesWithProxy.java.
How to configure proxy for azure service bus using java?
I try to connect to Microsoft for this problem so I find out that the previous version of queue client supports ConnectivityMode using TCP, HTTP, HTTPS, and AutoDetect. ServiceBus Explorer is using AutoDetect, trying TCP first and then failing over to HTTPS, regardless of the transport mode we were using (SBMP or AMQP).
With the new client this has changed. TransportMode now combines both options and offers Amqp (AMQP over TCP) or AmqpWebSockets (AMQP over WebSockets). There's no AutoDetect mode. You will have to create your clients and specify TransportType as AmqpWebSockets to bypass blocked.
I have set up the Azure SignalR Service for REST API. There are three modes under settings: Default, Serverless, Classic. I can't find any information about what each of these items sets. The only one thing I got so far, that if I use Azure SignalR for Azure Functions or REST APIs it's preferable to use Serverless option.
From documentation:
Change the Service Mode setting to Serverless only if you are using Azure SignalR Service through Azure Functions binding or REST API. Leave it in Classic or Default otherwise.
Serverless mode is not supported for ASP.NET SignalR applications. Always use Default or Classic for the Azure SignalR Service instance.
Could you please help me to find what each of these options sets?
According to the docs on Github, it determines whether a hub server connected to the SignalR service is needed or allowed:
Default mode requires hub server. When there is no server connection available for the hub, the client tries to connect to this hub fails.
Serverless mode does NOT allow any server connection, i.e. it will reject all server connections, all clients must in serverless mode.
Classic mode is a mixed status. When a hub has server connection, the new client will be routed to hub server, if not, client will enter serverless mode.
Because there isn't a hub server under serverless mode, the things you can do are limited to sending messages to specific clients or broadcast to all clients from a connected client. Also, as there is no hub, messages from clients to SignalR service will be sent over HTTP instead of Websockets, which may have performance concerns as detailed here.