I had a specific questin about angularjs with websocket. I currently have an application that utilizes a websocket to communicate with a server, this is all nice and dandy - and when I move around pages in angular the websocket persists throughout all of the routes which is neat. Unfortunately the problem is that if the user refreshes the page (for some dumb reason), the websocket disconnects. I was wondering what the best method of handling this is. Should I just have an alert when the user tries to refresh, can I somehow detect that the websocket is closed when the page is refreshed and start a new one? I'm just wondering what the best practice for something like this is.
Thanks
There is nothing you can do, if the user refreshes, it is like restarting an application, all the bootstrapping happens again and connections are created again.
You can use javascript:onbeforeunload to warn the user that if refreshes or leaves he will lose the connection. But your users will hate your for that, it is very annoying.
Consider as well, that the user may open several tabs.
Starting a new connection is the best way. Just make sure that the user can somehow recover his context. If there is a different context per tab, then you will have to put a connectionID parameter in the URL to persist it through refreshes, and if the context is per user session, then a cookie with the session ID will do.
Related
I'm trying to work a solution to timing out a user from my web application. I'm currently using ng2-idle and it seems to only work on the active window rather than be tracked server side (angular server webpack)
I need to handle these two events in addition to the one above:
On Browser Close
On Connection loss (Power cut, blue screen, etc..)
After testing, my timeout was not being tracked after closing the window. Ng2-idle has modules such as keepalive but I'm not exactly sure how to use it and if it solves my problem
I will provide code if needed
thank you
The main problem is, that the client and server are communicating in stateless manner. This means if the user disconnects no body knows.
If your browser has a hook function for closing or navigating to another site you could use that and send the logout request.
Another thing which relavant is session expiration, you should use that. If you are using a token you will need to blacklist that, as non active as long as the session may be valid (or however).
Disconnect is a major problem (session expiration tried to solve that somehow).
A more sophisticated way if it is really crucial to log out on disconnect you may need to use websockets or http long polling. You would need to send a heartbeat and if it's not responding, after some time you will automatically logout the user.
Hope these thoughts kind somehow help.
when you close your browser session will destroy.So you can use session to logout.
I am almost finished with a SPA application using AngularJS and Bootstrap. So far, I got everything working as desired, except for one thing: Proper handling with the users acts on the Browser's back or refresh buttons.
All the sub-pages within the application have buttons/links to the pages the user may switch to. Still, the application should handle properly back and refresh browser buttons. I should add that there is a login process to enter the application.
Also, all the critical information is stored under $rootScope, so everything is lost when the user refreshes and, in some cases, when he acts on the back button the results are not as desirable.
I actually have two questions:
What is the widely accepted standard behavior of applications like mine when browser buttons are acted on? (remember, there is a login process to begin with).
How should I start tackling the implementation of this approach?
One option I was thinking, is to intercept the request, warn the user that the action will log him off, and if the user cancels, force the browser to ignore the request (not sure this is possible).
Client side routing, each view in the application should have a URL. This week allow the browser buttons to work as expected, and gives your users the opportunity to link directly to a view.
The most commonly used client side router for angular is angular ui-router - https://angular-ui.github.io/ui-router
What is the widely accepted standard behavior of applications like
mine when browser buttons are acted on? (remember, there is a login
process to begin with).
If you are using REST services,
Store authentication token in your local storage or in a cookie
When user refresh the page send a request to server and fetch user information
If the request result in 401 then show login screen
This is one of sample applications I have done with this approach.
I have an application where I use socket.io alongside node.js. I can't find / figure out a way to check for events when users leave application i.e. close browser, refresh page, go back etc.. every one is connected in specific room. I need to know when someone leaves the room, know what their socket.io id was etc.. is there a method to achieve this?
Every time a user destroys the JS context by changing page (going back or forward, refreshing, closing the browser, etc), the Socket.io connection is closed, and that's how you get to know that (listen for the .on('disconnect') event on the server).
To deal with rooms, you may want to look at this page: http://socket.io/docs/rooms-and-namespaces/
I am using socket.io in my node.js application to give real time experience to my users. But due to leak of my experience with socket.io, I have some doubt with browser tab management. Let me explain first.
My website does not allowed login to user from multipul browser at a time. means If someone login from one browser, and then try to login from another browser, I have to kill previous login session. Means my socket.io emit messages to previous browser's all tab for logout, but my second browser's all tab should not get message for logout. How Do I do this?
Another question is I want to count distinct logged in users for my deshboard. But with multipul tabs, count is showing wrong figger. (eg. Single user accessing website from single browser but from 2 or more tabs, on server, socket client is showing each connection for tab, Here I need just one count. How Do I get it?
If some one has example/sample regarding above user case, please share it, so new coumer will gets help from it.
thanks
I'm having an issue with Socket.io receiving messages just before a page navigation happens - generally when the message is a direct result of some server-side action triggered by the navigation.
What I'm seeing right now looks like this:
Socket.io connects
User triggers a page navigation (submits a form, refreshes, etc.)
Server-side logic sends a request to the socket.io server, which immediately dispatches the event to the still-connected client
The client receives and confirms the request (I'm pretty sure there's some confirmation of messages built-in to socket.io, correct me if I'm wrong), and would display a notification to the user, but then ...
The socket.io connection closes on the original page
The new page loads and displays
Socket.io opens a new connection, but there's no new messages, because the last one was received and confirmed.
This isn't really a bug, per se, since I don't think it's reasonable to expect Socket.io to close the connection in advance of a navigation occurring. However, I'm not really sure what the best way to handle this is. Currently I keep one connection open per-client at a time, and close the other when a new one connects. This doesn't happen in this case though, since the first one has closed before the second one connects. I also could keep a list of all clients, but that wouldn't solve this problem either, because the message would still be received by the first connection.
Can someone suggest a solution to this problem that would ensure the user always sees a notification for the message?
Socket.io tracks logical connections with its own session IDs. If you watch the console when a client connects, you'll see the IDs:
info - handshake authorized Q9syoIK47JI7dACYpxiA
What's important to understand is that those IDs are per-page, and completely separate from HTTP sessions. The Socket.io client library simply holds its session ID in a JavaScript variable. Therefore, upon navigation, the ID is obviously lost.
So, upon navigation, this happens:
User is on a page connected to sio session 1.
We begin navigation to new page. On window.onbeforeunload, Socket.io initiates a synchronous XHR request to tell the server it is disconnecting. If it succeeds, the session (1) is immediately terminated; otherwise, the session will eventually time out.
A new page is loaded. It will connect to the Socket.io server and be assigned a new session ID, 2.
Anything you send to session 1 will obviously not be delivered since our client is now connected to session 2.
With the base Socket.io functionality, it is impossible to distinguish between a user who navigates between pages and a new user. In either case, the user will connect to a new Socket.io session.
Without knowing exactly how your app works or what you're trying to accomplish, it's hard to give a definitive recommendation for solving your problem.
Most likely, what you need to be able to do is associate a Socket.io session with the user's HTTP session. You can store notifications in a queue in the user's session, and delete them when they are displayed. There are two ways of doing this:
Since you're doing a full page load, you can send queued notifications directly down with the page itself. Delete the queue when you've successfully rendered.
On a new Socket.io connection, send unread notifications over the socket. Give .emit a callback function – this is the confirmation of delivery that Socket.io provides you. When delivery is confirmed, you can delete the notification queue from the user's HTTP session.
Simplest solution: Use the onbeforeunload event to disconnect socket.io.
I verified with a HTTP debugger that this event fires before the browser issues the request (at least in Chrome) so if socket.io is disconnected here, it won't receive any messages meant for the following page.
window.onbeforeunload = function() {
socket.disconnect();
};
I haven't tested this in multiple browsers, so it might not be a perfect solution, but it seems to solve the problem for now.