I'm using SignalR 2.2.2 to send users messages from my backend. When a user is logged in, and if other conditions are met, their connection is added to a group with the user's userId on my message hub.
It works great, as long as they have ~10 or fewer tabs/windows open. Any beyond that, they're stuck in "Loading..." indefinitely.
It seems to just be getting stuck on $.connection.hub.start();
I don't necessarily need to allow each user an infinite amount of signalr connections, but breaking the entire site for them on 10 open tabs is a problem.
OKAY BUT HERE'S THE THING. When I change my project's server setting from Local IIS to IIS Express, this problem vanishes! BUT! When we build the solution & put it on the test server, it's still broken.
What is going on???
I've tried catching or handling an error, but it still just hangs there.
$(function () {
if (loggedInUser != null)
{
var user = loggedInUser.UserId;
var messaging = $.connection.messageHub;
if (conditions) {
$.connection.hub.start().done(function () {
messaging.server.joinGroup(user);
});
}
}
});
I can get this to work with IIS Express. Now I need it to work like that on my test (and then later production) Server.
What else can I even try?
Related
I'm having incredible difficulty setting up the Twilio Client in Meteor JS, and would really appreciate any help.
I have extracted the relevant code and error logs below. So far as I can tell, it should be simple. The code is just grabbing an authtoken which I have previously generated, and then trying to set up the device using that authtoken. But it's not working.
'click #initializeDevice'(event) {
var thisAuthToken = Session.get('myAuthToken');
console.log(thisAuthToken); // I have confirmed with Twilio support that these authtokens are correctly generated
const Device = require('twilio-client').Device;
Device.setup(thisAuthToken, { debug: true });
var myStatus = Device.status()
console.log(myStatus); //this is logging "offline"
Device.on('ready',function (device) {
log('Twilio.Device Ready!'); //this is not logging anything
});
},
When that code runs, it generates the following logs:
eyJhbGciDpvdXRnb2luZz9hcHBTaWQ9QVA2NDE2MzJmMzA1ZjJiY2I[Note:I have deleted part of the middle of the logged authtoken for the purpose of this public post]5YmMxOGQyOWVlNGU2ZGM0NjdmMzRiNDVhNCIsImV4cCI6MTU3Nz0ygbJKTx15GgNCWDkm-iUPjn_O1NZU6yovp4vjE
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Setting up VSP
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 WSTransport.open() called...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Attempting to connect...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
calltemplate.js:31 offline
I'm doing this all from a local server, tunneled through NGROK. I've also set up the Twilio back end, linked the app, purchased a number, etc.
So far as I can tell, the issue, from the logs, appears to be something to do with the way that Meteor uses WebSockets.
Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
This is a not a Meteor related problem rather than browser issue.
Make sure your browser supports WebRTC
BTW, Your browser might be supporting it but you'd need to enable it.
IS there a way to trick the server so I don't get this error:
Content was blocked because it was not signed by a valid security certificate.
I'm pulling an iframe of an html website into another website but I keep getting the console (chrome) error in the title of this question and in internet explorer it says:
Content was blocked because it was not signed by a valid security certificate.
Your resource probably use a self-signed SSL certificate over HTTPS protocol.
Chromium, so Google Chrome block by default this kind of resource considered unsecure.
You can bypass this this way :
Assuming your frame's URL is https://www.domain.com, open a new tab in chrome and go to https://www.domain.com.
Chrome will ask you to accept the SSL certificate. Accept it.
Then, if you reload your page with your frame, you could see that now it works
The problem as you can guess, is that each visitor of your website has to do this task to access your frame.
You can notice that chrome will block your URL for each navigation session, while chrome can memorise for ever that you trust this domain.
If your frame can be accessed by HTTP rather than HTTPS, I suggest you to use it, so this problem will be solved.
Sometimes Google Chrome throws this error, even if it should not.
I experienced it when Chrome had a new version, and it needed to be restarted.
After restarting the same page worked without any errors.
The error in the console was:
net::ERR_INSECURE_RESPONSE
I still experienced the problem described above on an Asus T100 Windows 10 test device for both (up to date) Edge and Chrome browser.
Solution was in the date/time settings of the device; somehow the date was not set correctly (date in the past). Restoring this by setting the correct date (and restarting the browsers) solved the issue for me. I hope I save someone a headache debugging this problem.
Offering another potential solution to this error.
If you have a frontend application that makes API calls to the backend, make sure you reference the domain name that the certificate has been issued to.
e.g.
https://example.com/api/etc
and not
https://123.4.5.6/api/etc
In my case, I was making API calls to a secure server with a certificate, but using the IP instead of the domain name. This threw a Failed to load resource: net::ERR_INSECURE_RESPONSE.
open up your console and hit the URL inside. it'll take you to the API page and then in the page accept the SSL certificate, go back to your app page and reload.
remember that SSL certificates should have been issued for your Dev environment before.
If you're developing, and you're developing with a Windows machine, simply add localhost as a Trusted Site.
And yes, per DarrylGriffiths' comment, although it may look like you're adding an Internet Explorer setting...
I believe those are Windows rather than IE settings. Although MS tend to assume that they're only IE (hence the alert next to "Enable Protected Mode" that it requries restarted IE)...
Try this code to watch for, and report, a possible net::ERR_INSECURE_RESPONSE
I was having this issue as well, using a self-signed certificate, which I have chosen not to save into the Chrome Settings. After accessing the https domain and accepting the certificate, the ajax call works fine. But once that acceptance has timed-out or before it has first been accepted, the jQuery.ajax() call fails silently: the timeout parameter does not seem help and the error() function never gets called.
As such, my code never receives a success() or error() call and therefore hangs. I believe this is a bug in jquery's handling of this error. My solution is to force the error() call after a specified timeout.
This code does assume a jquery ajax call of the form jQuery.ajax({url: required, success: optional, error: optional, others_ajax_params: optional}).
Note: You will likely want to change the function within the setTimeout to integrate best with your UI: rather than calling alert().
const MS_FOR_HTTPS_FAILURE = 5000;
$.orig_ajax = $.ajax;
$.ajax = function(params)
{
var complete = false;
var success = params.success;
var error = params.error;
params.success = function() {
if(!complete) {
complete = true;
if(success) success.apply(this,arguments);
}
}
params.error = function() {
if(!complete) {
complete = true;
if(error) error.apply(this,arguments);
}
}
setTimeout(function() {
if(!complete) {
complete = true;
alert("Please ensure your self-signed HTTPS certificate has been accepted. "
+ params.url);
if(params.error)
params.error( {},
"Connection failure",
"Timed out while waiting to connect to remote resource. " +
"Possibly could not authenticate HTTPS certificate." );
}
}, MS_FOR_HTTPS_FAILURE);
$.orig_ajax(params);
}
This problem is because of your https that means SSL certification. Try on Localhost.
I'm seeing some odd/unexpected behaviour using the SignalR 2.0.3 libraries.
I'm trying to hook some call backs in the client and they don't seem to be getting fired.
I'd really like to get the reconnecting, reconnected and disconnected call backs working in JS - client side.
SignalR does connect successfully and I've got communication between the server and client.
Here are a couple of code snippets:
$.connection.reconnecting = function () {
alert("reconnecting");
};
$.connection.reconnected = function () {
alert("We have been reconnected");
};
$.connection.disconnected = function () {
alert("We are disconnected!");
};
I could have sworn that I had these firing when I was using SignalR 1.x.
Currently, we using version 2.0.3.
I'm running a 2 machine setup where my server app (and hub) is on 1 machine.
Here are the steps I'm using to reproduce:
1) Connect from a second machine. I looked at the network traffic in the browser
console and it looks ok.
2) Next I disconnect the client machine from the network. In the console I see SignalR
attempting to reconnect. (This is as expected)
3) Ultimately after N retries, it looks like it disconnects. (I see the final retry is "Canceled"
in the console output.
4) However, my disconnected() handler does not get called.
Any insights or thoughts how to track this down?
Thanks,
JohnB
With SignalR 2.x, you can register your callbacks like this:
$.connection.hub.reconnecting(function() {
alert("reconnecting");
});
$.connection.hub.reconnected(function() {
alert("We have been reconnected");
});
$.connection.hub.disconnected(function() {
alert("We are disconnected!");
});
You can also add callbacks using $.connection.hub.stateChanged(). See documentation.
I have backend meteor server which serves and shares common collections across multiple apps (just sharing mongo db is not enough, realtime updates are needed).
BACKEND
/ \
APP1 APP2
| |
CLIENT CLIENT
I have server-to-server DDP connections running between backend server and app servers.
Atm i'm just re-publishing the collections in app server after subscribing them from backend server.
It all seems working quite well. The only problem tho is that in app server cant query any collections in server side, all the find() responses are empty, in client side (browser) it all works fine tho.
Is it just a coincidence that it works at all or what do you suggest how i should set it up.
Thanks
I realize that this is a pretty old question, but I thought I would share my solution. I had a similar problem as I have two applications (App1 and App2) that will be sharing data with a third application (App3).
I couldn't figure out why the server-side of my App1 could not see the shared collections in App3...even though the client-side of App1 was seeing them. Then it hit me that the server-side of my App1 was acting like a "client" of App3, so needed to subscribe to the publication, too.
I moved my DDP.connection.subscribe() call outside the client folder of App1, so that it would be shared between the client and server of App1. Then, I used a Meteor.setInterval() call to wait for the subscription to be ready on the server side in order to use it. That seemed to do the trick.
Here's a quick example:
in lib/common.js:
Meteor.myRemoteConnection = DDP.connect(url_to_App3);
SharedWidgets = new Meteor.Collection('widgets', Meteor.myRemoteConnection);
Meteor.sharedWidgetsSubscription = Meteor.myRemoteConnection.subscribe('allWidgets');
in server/fixtures.js:
Meteor.startup(function() {
// check once every second to see if the subscription is ready
var subIsReadyInterval = Meteor.setInterval(function () {
if ( Meteor.sharedWidgetsSubscription.ready() ) {
// SharedWidgets should be available now...
console.log('widget count:' + SharedWidgets.find().count);
// clean up the interval...
Meteor.clearInterval(subIsReadyInterval);
}
}, 1000);
});
If there is a better way to set this up, I'd love to know.
I have done this already,
check my app Tapmate or youtap.meteor.com on android and iphone,
I know it will work till 0.6.4 meteor version,
haven't checked if that works on above version,
You have to manually override the default ddp url while connecting,
i.e. go to live-data package in .meteor/packages/live-data/stream_client_socket.js
overwrite this - Meteor._DdpClientStream = function (url) {
url = "ddp+sockjs://ddp--**-youtap.meteor.com/sockjs";
now you won't see things happening locally but it will point to meteor server
also disable reload js from reloading
Thanks
I'm using SignalR but have run into a problem. When a connection is started in one browser window and then a user logs in in another browser window the User identity is changed (this causes the error 'System.InvalidOperationException: Unrecognized user identity. The user identity cannot change during an active SignalR connection' on the server when a method is called on the hub.
I'm using this code on the client:
proxy.server.analyze(content)
.done(function () {
console.log('Success!');
})
.always(function () {
console.log('This is always called!');
})
.fail(function (error) {
console.log('This is never called!');
});
When I'm seeing errors on the server the fail function is never being called so there appears to be no way on the client to handle this problem and stop and start the connection.
So is there a "best practice" way of handling this case? How can I detect on the client that the user identity has changed in another browser window and stop and re-start the connection?
This is a known issue.
It is fixed in the next release. Here's the issue that ended up also fixing your issue: https://github.com/SignalR/SignalR/issues/2106.
Lastly, in the next release (0.2.0) what will happen is the connection will throw an error and stop itself. Therefore you'll be able to handle your case via either the error handler or you can of course you can tie into the "disconnected" event.
If you're willing to try a pre-releases you can always pull from the offical source or webstack nightly (http://www.myget.org/F/aspnetwebstacknightly/)