Aspnetcore: Cannot connect from a non-browser Javascript client to Asp.Net Core SignalR

[christiansita]

Hi, I am trying to write a non-browser javascript client to connect to my Asp.Net Core SignalR and I am having the following error message:

Debug: Starting HubConnection.
Debug: Starting connection with transfer format 'Text'.
Debug: Sending negotiation request: https://localhost:44339/chatHub/negotiate
Error: Failed to complete negotiation with the server: Error: callback argument missing
Error: Failed to start the connection: Error: callback argument missing

My Javascript non-browser javascript client code is as follows(this client powered with Node.Js):

global.XMLHttpRequest = require('xhr');
var signalR = require('@aspnet/signalr');
var connection = new signalR.HubConnectionBuilder()
.withUrl("https://localhost:44339/chatHub")
.configureLogging(signalR.LogLevel.Trace)
.build();
connection.on("receivemessage", function(user, message) {
var msg = message.replace(/&/g, "&").replace(//g, ">");
var encodedmsg = user + " says " + msg;
console.log(encodedmsg);
});

connection.start().catch(function(err) {
//return console.error(err.tostring());
});

My Asp.Net Core SignalR is that exact implementation from this tutorial: click here

One the Server-side, I am using:

• Microsoft.AspNetCore.SignalR version 1.0.3
• Microsoft IIS Express (Visual Studio 2017 version 15.8.1)
• C#
• Operating System: Windows 10 version 1803

On the client side:

• Node.js version 9.11.1
• Visual Studio Code version 1.26.1
• ASP.NET Core SignalR JavaScript Client version 1.0.3
• Module xhr, version 2.5.0

[christiansita]

Hi,
I polyffiled Websocket on my non-browser javascript client and skipped negotiation
global.WebSocket = require('websocket').w3cwebsocket;
var connection = new signalR.HubConnectionBuilder()
.withUrl("https://localhost:44339/chatHub", { skipNegotiation: true, transport: signalR.HttpTransportType.WebSockets })
.configureLogging(signalR.LogLevel.Trace)
.build();
Now, I am getting the following Error message:
_

Debug: Starting HubConnection.
Debug: Starting connection with transfer format 'Text'.
Trace: (WebSockets transport) Connecting
Trace: (WebSockets transport) socket closed.
Error: Failed to start the connection: undefined

_

[BrennanConroy]

"xhr" doesn't seem to be a valid polyfill for XMLHttpRequest. Take a look at one of our samples that uses a polyfill that works https://github.com/aspnet/SignalR-samples/blob/master/StockTickR/NodeClient/app.js

As for your websocket issue, does your server support websockets? Could you collect the server logs?

[christiansita]

Hi, Brennan.

Thanks for your reply. I updated the polyfill and enabled WebSockets protocol as per this suggestion.
Still my non-browser client cannot connect to Asp.Net Core SignalR via WebSocket.
Here are my Server's logs:
ex180828.log
ex180829.log

[anurse]

Those logs you provided are the HTTP request logs from IIS, we need the actual server application logs to be able to get more detail. Can you post both client and server application logs as described in the Diagnostics Guide?

[bradygaster]

During the authoring of a small Node.js app that makes use of the npm package, I ran into a similar issue. I added these lines (and executed the requisite npm install commands), and things worked just fine.

If this isn't already in our guidance or documentation, I think it'd be valuable for us to call it out for JavaScript developers who might want to make use of the library and the Azure SignalR Service as their back-end for things.

[davidfowl]

@bradygaster it's all fixed in 2.2. See https://github.com/aspnet/SignalR/issues/2535

[anurse]

Yep, 2.2 will support direct usage from Node with no polyfills. We bring in the polyfills ourselves now.

[bradygaster]

@anurse @davidfowl thanks for the info. I was thinking of adding something to the code example on the NPM page here via the readme that would show how to pull those polyfills in (in my case, websockets and xmlhttp). I presume we should wait until 2.2. goes out.

[davidfowl]

I was thinking of adding something to the code example on the NPM page here via the readme that would show how to pull those polyfills in (in my case, websockets and xmlhttp)

Do you mean we should update the 1.0.x package right now to show how to use it with node? Do we have any docs on this?

[bradygaster]

@davidfowl Not sure i think that would be my goal. What I was more or less talking about is, on the NPM page for the package, we simply show the two lines i referenced above in the sample code. I could submit a PR so you know what I mean. Basically give folks sample code that works out-of-the-box rather than make customers find this (or another) issue/thread with the workaround until 2.2. comes out. If 2.2. is like REAL SOON, ignore me. :)

[davidfowl]

So yes, you're saying you want to update the 1.0.x package to show how to use it right now. 😄

[bradygaster]

Yes, @davidfowl, i guess that's what i'm saying. :) I created this PR, as it was what got me working when I was iterating on a quick sample. Understand if this is a point-in-time thing that we don't need to waste time on but just-in-case it's as easy as a doc bug fix that could enable people to party on it today, here we go.

[anurse]

A doc change would be best, probably to this doc: https://docs.microsoft.com/en-us/aspnet/core/signalr/javascript-client?view=aspnetcore-2.1 adding a note about how to enable the polyfill.

Changing the README is trickier since it ships in the package which means we either:

1. Ship the updated README in a 2.1.x patch, which means it has to go through shiproom. As a README-only change, it should sail through no problem, but it has to go through.

2. Ship the updated README in 2.2, which is unnecessary since 2.2 supports Node natively.

I think a doc change is sufficient here and we can leave the README as-is, but I'm open to being convinced otherwise :)

[bradygaster]

@anurse I definitely agree a few doc updates are in order and I can help facilitate that. That said, i also think the readme change would be a good thing for getting folks up and running via the code introducing them to the client. IMO, if the "process cost" is as insignificant as a bullet during shiproom, i'll argue and/or take said bullet (feel free to give the new guy the work, I'm the one on the hill dying for the simple tweak so i'm comfortable doing the lifting if that'll make life easier.

To me, the NPM readme is "the first thing the user sees," and when the sample code fails to work, the more impatient readers will bail or flail, or presume it is broken or doesn't work. Not all would do the research to determine it's a simple manual dependency add.

But I can be talked of the ledge. If this is soon, I can stop randomizing. I can also augment the docs if that's optimal.

[anurse]

Yep, not worried about getting it through, it's easy, we just need to target the right version since the added code is not needed in 2.2/3.0

[Havunen]

So if anybody else faces this issue you can install next version using following command

npm i --save @aspnet/signalr@next

[aspnet-hello]

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.