Connecting to Strophe.js in Angular 6 - xmpp

I have connected to Strophe.js by placing the Strophe.js files in assets and Connection is successful. But after connecting to it, UI is getting hanged. Can any one please help

what means hanged? Strophe.js does't block the process.
i remeber connect like this(not exact code):
var callback = function(condition){
// according to condition decide if connected or not
// and if connected, UI: form login panel to main panel(include friends list and so on)
}
Strophe.connection(jid, password, callback);
and there is no reason UI hanged. you may use broswer debug tool to follow your code and find out where it hanged

Related

How to change end session message "I'm having trouble connecting to the server, please refresh the page"-Watson Conversation

I am doing the chatbot for another language and I would like to change the message after en session: "I'm having trouble connecting to the server, please refresh the page".
I don't find where it is define
Assuming you're using the Node.js implementation provided by IBM, you can customize the message by editing line 76 of api.js (located here for reference).

How to receive publish/message event from Sails server using Socket.io swift client

Currently i am building app using Sails server as a backend and iOS Swift as a client.
I am able to emit from iOS side to create user and receive data from server side, but i am not able to get PubSub methods(message, publishAdd, Update,etc) provided by sails.
Here is my server side code
User.subscribe(req, [userdata.id]);
Now when there is any update occurred on above User recored then i need to receive event like
socket.on("userupdate") { data in
print("user 1 ------------>", socket)
}
But i am not receiving any event on client side.
Any help will be appreciated :)
Thanks
Actually i am missing watch on server side also need to do changes on client side like below
socket.onAny({ data in
print("ANy event =====> \(data)" )
})
socket.on("user", callback: {
data,ack in
print("call back called \(data) \(ack)")
})
socket.OnAny user to trace which event being called while there is any event for publish, update,etc
Here are server side changes i have done
User.subscribe(req, newUser, ['message']);
User.watch(req);
User.publishCreate(newUser);
Hope this will be useful for developer looking to implemented socket with Sails server.

SignalR seems to not be using the root path that I give it when trying to connect

I have my SignalR server listening on the following URL:
http://staging.myserver.com/socket/signalr
I tested locally and it works, but when I deploy, I am running through an NGINX proxy (hence the /socket/)
When it tried to connect to the deployed SignalR server, it is failing and I can see that it is attempting to connect using a URL with the /socket/ ommitted.
I have tried to debug to see if there is a sport where it strips everything but the base url and appends /signalr but I can't seem to find anything.
I am able to hit the following URL and see my hubs perfectly fine.
http://staging.myserver.com/socket/signalr/hubs
I just don't know why it is omitting the /socket from the url when trying to connect.
Here is more or less an example of what I have
var connection = $.hubConnection('http://staging.myserver.com/socket/signalr');
var contosoChatHubProxy = connection.createHubProxy('contosoChatHub');
contosoChatHubProxy.on('addContosoChatMessageToPage', function(name, message) {
console.log(name + ' ' + message);
});
connection.start().done(function() {
//blah blah
});
I can see it taking the correct URL when it first initializes the connection, but somewhere along the way, it defaults back to
http://staging.myserver.com/signalr
The only way I have been able to get around it is by adding an addition proxy to / on my NGINX proxy. This is not something that will be able to stick so I need to figure it out.
Please see GitHub issues #3649 and #3287 which describe the same issue and give some pointers specific to IIS on how to transform the content within the response to the connection negotiation to re-write the URL property. It appears that the URL within the response from the server is used to set a local variable called appRelativeUrl on the client side which is used for subsequent interaction. So another less palatable workaround is to modify/configure the SignalR server using app.MapSignalR("/socket/signalr", hubConfiguration); but I haven't gone that route to see whether it would cause other problems.

Real time model events in Sails.js 0.10-rc5

I've been playing around with building some realtime functionality using Sails.js version 0.10-rc5 (currently the #beta release).
To accomplish anything, i've been following the sweet SailsCast tutorial on this subject (sailsCast link)
It talks about subscribing to a model via a 'subscribe' action within the model's controller. Then listening to it at the client side, waiting for the server to emit messages. Quite straightforward, although I do not seem to receive any messages.
I'm trying to do this to get real-time updates on anything that changes in my User models, or if new ones get created.. So I can display login status etc. in real time. Pretty much exactly the stuff that's explained in the sailsCast.
In my terminal i'll get two things worth noticing, of which the first is the following:
debug: Deprecated: `Model.subscribe(socket, null, ...)`
debug: See http://links.sailsjs.org/docs/config/pubsub
debug: (⌘ + double-click to open link from terminal)
debug: Please use instance rooms instead (or raw sails.sockets.*() methods.)
It seems like the 'subscribe' method has been deprecated. Could anybody tell me if that's correct, and tell me how to fix this? I've been checking out the reference to the documentation in the debug message, although it just points me to the global documentation page. I've been searching for an answer elsewhere, but haven't found anything useful.
The second message I'm getting is:
warn: You are trying to render a view (_session/new), but Sails doesn't support rendering views over Socket.io... yet!
You might consider serving your HTML view normally, then fetching data with sockets in your client-side JavaScript.
If you didn't intend to serve a view here, you might look into content-negotiation
to handle AJAX/socket requests explictly, instead of `res.redirect()`/`res.view()`.
Now, i'm quite sure this is because I have an 'isAuthenticated' policy added to all of my controllers and actions. When a user is not authenticated, it'll redirect to a session/new page. Somebody must log in to be able to use the application. When I remove the 'isAuthenticated' policy from the 'subscribed' action, the warnings disappear. Although that means anyone will get updates via sockets (when I get it to work), even when they're logged out. - I don't really feel like people just sitting at the login screen, fishing out the real time messages which are intended only for users who are logged in.
Can anyone help me getting the real time updates to work? I'd really appreciate!
As far as the socket messages not being received, the issue is that you're following a tutorial for v0.9.x, but you're using a beta version of Sails in which PubSub has gone through some changes. That's covered in this answer about the "create" events not being received.
Your second issue isn't about sockets at all; you'll just need to reconsider your architecture a bit. If you want to to use socket requests to sign users in, then you'll have to be more careful about redirecting them because, as the message states, you can't render a view over a socket. Technically you could send a bunch of HTML back to the client over a socket, and replace your current page with it, but that's not very good practice. What you can do instead is, in your isAuthenticated policy, check whether the request is happening via sockets (using req.isSocket) and if so, send back a message that the front end can interpret to mean, "you should redirect to the login page now". Something like:
module.exports = function (req, res, next) {
if ([your auth logic here]) {
return next();
}
else {
if (req.isSocket) {
return res.json({status: 403, redirectTo: "/session/new"});
} else {
return res.redirect("/session/new");
}
}
}

Debug gwt inside facebook iframe

I'm trying to debug my gwt 2.0 apllication that runs inside facebook iframe.
When i use 'http://127.0.0.1:8888/index.html?gwt.codesvr=127.0.0.1:9997' as "Canvas Callback URL" my app doesn't loading, but when i compile it and use 'http://127.0.0.1:8888' it works perfectly.
There is a cross site scripting issue with using the GWT debugger within the facebook iframe.
I logged this as issue #4468
http://code.google.com/p/google-web-toolkit/issues/detail?id=4468
Within that ticket, I specified the workaround is to edit the hosted.html file thusly:
hosted.html
gwtOnLoad = function(errFn, modName, modBase){
....
var topWin = window.top;
var url = topWin.location.href;
...
Workaround if you have one:
var topWin = window;
var url = topWin.location.href;
I have a similar issue for deployment mode. Basically I want my GWT to be managed from a single entry point deployment and be able to run it as widget on 3'rd party websites, without them have to download my application into their host, only using the selector script as reference to my GWT app.
There is a problem doing that due to SOP limitation of current bootstrap process that uses an "iframe" to load the compiled script asynchronously.
I created a workaround procedure for that, let GWT app be installed using 'script' instead of 'iframe'. This makes my GWT available for 3'rd party websites, and let me maintain a single entry point of deployment.
The following article describe my workaround procedure:
Make GWT Widget Avialble For 3'rd party websites
127.0.0.1 is a reserved IP address that always resolves to localhost. So when you enter that as a Facebook canvas URL, Facebook tries to access it's own servers. A request never comes to your computer, which is where the application is actually hosted. Of course, when you access it at 127.0.0.1, it works fine, because your localhost is your own machine.
You need to figure out your external IP address, and enter that as the Canvas Callback URL. You can check your router settings, or go to something like http://www.whatismyip.com/. Once you have it, try accessing your application using it directly instead of 127.0.0.1. You might have to change your router or firewall to allow port 8888 through. Once you have it working, enter it as your Canvas Callback URL in your Facebook application settings.