In my scenario, I am using SignalR for login purpose.
If user one is logged in with username 'abc' and user two login with the username 'abc', user one will be kicked and redirect two login page.
But if user one is logged in and it refreshes the page and then user two tries to logged in user one will not get kicked. Because while refreshing user one has lost the connection. I tried lots of solutions like trying to reconnect on disconnect event, but its not working.
Can anyone help in this?
Client Disconnection Scenarios
In a browser client, the SignalR client code that maintains a SignalR connection runs in the JavaScript context of a web page
When the user closes a browser window or tab, or navigates to a new page or refreshes the page, the SignalR connection immediately ends because SignalR client code handles that browser event for you and calls the Stop method. In these scenarios, or in any client platform when your application calls the Stop method, the OnDisconnected event handler executes immediately on the server and the client raises the Closed event (the event is named disconnected in JavaScript)
Disconnection Scenarios(Client & Server)
Related
I have an application that asks a user to login with Reddit. When they accept, it opens a new window (call it SpawnedWindow), Reddit asks them if they want to connect, and when they do, SpawnedWindow redirects to a GET endpoint on my server with the success/failure information. My server will do some computation to figure out if the auth was really successful, and if it is, it will send an "ok" (as a response to the GET request) to SpawnedWindow.
I want the original page to detect this "okay" and continue with user onboarding. How might I communicate this between the new window and the original window?
If you're familiar with "login with Google" buttons: as we know, there's a popup, and depending on the result of authentication, the main page will have dynamic behavior (based on the login being successful or not). This is essentially what I'm trying to achieve.
The API (and many APIs which have a similar authorization process) provides a redirect_uri that the user will be redirected to after authorization succeeds. You can pass a redirect_url query parameter that goes to a page on your site. This way, once authorization succeeds, the newly opened page (on your site, that Google has redirected the popup to) can communicate to the original page (on your site).
One way to do this is with a BroadcastChannel - open a channel on your original page, and wait for a message. On the new page, open the same channel and send a message, and the old page can listen for the message.
Another option would be to use Local Storage. On the original page, listen for storage change events. On the new page, change storage so as to fire the event.
We are using the Twilio Programmable Chat JavaScript SDK (v. 4.0.0) to build a chat application.
We have several channels for each user and we listen on every channel for messages via the messageAdded-Event.
After a disconnect the client is reconnecting normally, but no events for messages sent in the meantime are fired.
Example:
User A: Client goes offline
User B: Sends message
User A: Client goes online
User A: Client is "connected"
User A: No Event for new message
We would expect that after the client has re-established connection we would get events for the "missed" messages/created channels; especially as the docs state (probably only meant for the client, but whats the point then?):
There is no need to implement shutdown/create cycle on network drops →
SDK reconnects automatically after regaining network.
Is this intended behaviour?
What would be the best way to retrieve "missed" events? Reload channels/messages manually?
(3) Another problem we discovered is, that sometimes the client is not able to reconnect at all, which results in a lot of Retrier attempt is already in progress, Twilsock: request timeout error messages. Any ideas on that?
I am working on a page where a user can lock records when he is working on them. While working on the records, a session (via RESTful API) locks records. Every 15 seconds, I am sending a "heartbeat" signal to my API to show that the session remains active.
I also have a "onBeforeUnload" function, which gives a warning when someone has made changes, but did not save them.
My problem is: While the beforeUnload dialog is up and running, it seems that te rest of my javascript code is not executing. This means that my heartbeat is not sending, and a background job will remove the session if the dialog is up for too long.
Is there any way to keep sending my heartbeat signal sending, while the beforeUnload dialog is active?
The way authentication works in our webapp is that after 2 mins of user idle time it redirect the next HTTP request to the auth server to refresh access token which is then placed in a cookie which is used to authenticate subsequent HTTP requests. So, if the user is idle longer than 2 mins and then tries to submit a form, the redirect to auth server loses form data and sends the user back to the empty form.
We have no control over the auth server and would like to come up with a mechanism that would periodically perform a background redirect to auth server without leaving the current page. One option is to use an embedded iframe, but this makes it nontrivial setting the cookie on the main page after the redirect. Is it possible or appropriate to use HTML5 web workers for that? Any other solutions?
Thanks
I am writing a website that is essentially a client-side web app, i.e. everything on the page is populate by scripts with data from ajax APIs. Users would be also signing in and signing out using a set of APIs.
My question is about how do deal with the following (but not quite extreme) use case:
User opens browser tab A and go to the website and logged in as user #1.
User opens browser tab B and also go to the website. Since there is a get_session API, the script restores the session on tab B.
User logged out from tab B while leaves tab A open.
User forgets about tab A for sometime, and go back and interactive with tab A.
Scripts in tab A attempts to fetch new data as user #1 but encounter error.
Ideally, there should be some way in step 3 that the tab A would also log itself out when user clicked logged out in tab B.
It's possible to log out tab A in step 5 (GMail do that), but I think there should be a better way. Even checking in step 5 would be non-trivial, cause for such design every API must know exactly which user's data the script is requesting, or the below use case would generate incorrect output.
(1-3) same as above.
User opens browser tab A and go to the website and logged in as user #1.
User opens browser tab B and also go to the website. Since there is a get_session API, the script restores the session on tab B.
User logged out from tab B while leaves tab A open.
User log in again from tab B but this time as user #2.
User goes back to tab A and interactive. While thinking the user is user #1, the script in Tab A request data from API.
API returns data that belongs to user #2. Boom.
Is there a common practice to prevent these kind of problem? Thanks.
Tim
The ajax response should indicate as an error condition that the user has logged out; on the client side, detect this error and perform the appropriate action. Obviously this only works when there is an ajax response, so you might want to implement some kind of 'hearbeat' mechanism, that is, the client sends a ping-like ajax message to the server every few seconds. When you log out, the server will respond to the heartbeat with a 'user logged out' error, and the client can go into 'not logged in' mode.
I don't think there is, because such communication between pages (tabs) would be a significant security weakness.
However, you could achieve the same effect by having each page (tab) polling the server to see if the session is still valid. Or use one of the event-handling techniques such as long-polling or streaming in an iframe.