I was wondering what the best way of implementing a timer in the frontend would be.
The idea is to notify the user after 13 minutes of inactivity (= not made a request to the backend) that he will be logged out in 2 minutes.
My first attempt was to just use a Timer which is executed every second (I am doing this with Flutter web but it shouldn't make a difference) and counts down from 15 minutes.
Then we tested this internally and noticed that the Browser somehow stops JavaScript execution if the user switches to a different tab for a long time or if the computer goes into stand by such that the timer stops.
We already have a session timeout after 15 minutes from the backend, this is just to make the user experience better.
How would this be correctly implemented?
For short, I think it's impossible for only using frontend
As you examine, the javascript code will be stop whenever switching tab or close tab, computer stands by. So that it will not be good to use a timeout or something like that.
I used an idea before but not implemented it yet because I switched to simpler idea with sessionStorage. But you could see and somehow success with it: when last request is made, created a cookie with expire time is 13 minutes. If next request is made, clear old cookie and add a new cookie with 13 minutes too. If the request will not made during 13 minutes, when cookie expire, fire a event to annouce to user. To listening cookie change, I think there are a lot solutions out there. But for me, this idea is not so good so I forgot it.
If you can use a nodejs backend, you could try to use Server Send Event - SSE. This will create one-way sending data. Therefore you can stream a chunk of data. And the frontend will listen that streaming and decide whether to annouce to user.
Related
I'm seeking the best way to keep the data up-to-date when dealing with web socket async requests, especially data that contain time information.
I have a dashboard, when I logged/pressed feed I updated the nextFeed time to feedingInterval + the current logged time.
feedingInterval = 2 hrs
I used to do form submit, and page refresh.
Also, I used to do location.reload() every 1 minute to keep my nextFeed time up-to-date when my user opened up the link on a machine connected to a TV.
nextFeed time always up to date, worse case there is 1 mn lagged.
NOW
To enhance the UX:
I don't use form submit anymore, so no page refresh, I use Ajax POST to a web socket route to broadcast to all my devices. When I receive any push notifications from Pusher Cloud, I update the DOM live dynamically on all my devices.
Issue
I used to refresh my page every 1 minute, since I didn't do ( location.reload(); ) anymore. My feeding time will become stale (not up-to-date).
Current solution:
I created an API to get the nextFeed time, called it every 5 seconds, and update DOM every 5 seconds. I notice my browser seem very hot since, maybe due too much requests in a minute.
Then you might say/think... just called every minute then ...
But ... If I make a call every one 1 minute then my users wont' have up-to-date information which defeats the purpose of me doing the websocket in the first place.
What should I do to have the best UX, but not too compromise my performance?
https://www.bunlongheng.com/baby/5db53c4c-5be4-4aa2-b9f6-b564acb871ac?code=d3s!gn
I want to make a custom tracking system for web events. I have looked into multiple per-excsiting systems, but I want something terribly simple - yet very accurate.
I want to be able to track the following:
Page view even
Time on that page
or:
Video started playing event
Time of video watched
My first initial thought was to do a simple javascript reporting back to the server, but what happens if the user closes the window? How do I know they stopped viewing? And how can I get accurate measurements down to 1/10th of a second? So I thought of a websocket solution, as it know when a user has discounted. I ended up with Socket.io, but I want to make sure there is no better or smarter way to achieve this?
How would you approach his challenge? What is the smartest way to engineer this?
A Websocket connection which reports back to the server frequently was my first thought as well, but if you send 10 messages every second, even that might be too much for a websocket, especially when connectivity isn't top-notch.
Since the server doesn't require the information absolutely immediately, consider batching requests instead - save/update the information into Local Storage every 0.1 seconds, but don't send it to the server then - instead, every 30 or 60 seconds, or on pageload, take the current data in Local Storage and send it to the server, and clear Local Storage so that the next request a minute from now doesn't send duplicate data.
Here is a new requirement that I need help with. Our users request that 2 minutes before the session timeout, warn them. (i can use a global javascript to check on every page since once a page is loaded, the session reset and by default, another 20 minutes is extended). at the 18th minute, a javascript popup shows up, asking the user "You have two minutes left before being logged off. Do you want to extend the session"?
Up to here, all is fine. But then once they hit "Extend it", then what? I don't want to refresh the page because the data they've already entered will be lost. Is Ajax needed? If so, what is the programmatic way to extend the current session? (not modifying web.config just to be clear)
Also, say they are talking to someone and did not see the javascript confirmation during the 2 minute. Is there anyway to "hold" the session, till the user decides to do something?
Thanks
I was recently working on a similar problem. With ASP.Net every call back to the sever resets the session timeout period. So a Ajax call is going to be your best bet.
As for holding the session, are you actually storing anything in the Session object that needs to be maintained? Or when you say session do you mean the period that the user is authenticated for? If it is truly Session and you are not storing data then it shouldn't matter id it expires. You may want to take a look ar the below link.
Forms authentication timeout vs sessionState timeout
I'm looking for a JavaScript code to destroy the session of users which aren't active. (It's for a live chat site)
Expiry:
The website detects every 5 minutes the activity of a user and then it updates the database with the last activity timestamp. So if the user didn't wrote since 2 minutes ago, the last activity timestamp would be time()-120 (120=2minutes)
And now I will that a js code can detect if the last activity timestamp is more than 300 seconds (5 minutes in seconds) ago, to destroy the session of the inactive user.
With php it would be easy, only it would need a refresh of the page and then the user would be logged out. Is there a chance to do this with javascript without refreshing the page? If inactive -> destroy session and automatically logout, so the user can't write anymore.
Thank you.
The session is a backend concept and can not be directly controlled with frontend Javascript. Sessions refer to information that is stored on the server and linked to the frontend user in some way, usually with a session cookie.
What you can do is either remove the cookie and wait for the session to die on the server, or write a PHP script that invalidates the session immediately and call that over AJAX. Either way, you'll have to change the UI with Javascript to let the user know they've been logged out, for example by disabling the text inputs and halting the script that polls for new messages.
Please also note that terminating the session for an idle user without warning is bad UX and will annoy your users. At least give them a notice beforehand that their session will be dropped in two minutes because of inactivity so they can react to stay online.
I am creating an auction site in which the auction has a particular end date/time.
I have a javascript timer displaying the remaining time to the user and when this countsdown it fires and event to update the back end mongodb database to say the auction has completed and it informs the winning user and fires a CLOSE function.
How would you recommend doing this for auctions that aren't physically open in a browser at the time so the Timer event never creates this CLOSE event.
I wouldn't recommend this approach at all. Once I was working on a website and I needed to implement auctions. The project was in php so I wrote a php script which checks all auction rows in the database and looks for those with the timeEnd >= current time and sets their status to closed(The auctions table had int column for the status).
Then I set that php script to run as a cron job once every hour. So now the server automatically runs this server side script every hours and checks for out-dated auctions. The interval depends on the business logic of the app. For this project the auctions could only end or start to the beginning of every hour. This approach is far better than using javascript code that triggers the server script. One reason is that you can't trust client side code. Hackers could potentially get access to that javascript file and easily modify it. You should never let your server code depend on your client side code.
However, note that my approach is not the most ideal because depending on how much auctions your db have, the server script will still need time to process it and might take from a few seconds to couple of minutes to execute it.
For example if you have some auction that ends at 10:00:00 and the server script start executing at 10:00:00 and it takes 40 seconds to execute, the users could potentially find a way to place bid on those auctions in the interval of that 40 seconds. Your client side code should only take care for resetting the interface right at 10:00:00 so that users are not able to place bids. However, you should also make sure that the server-side code that handles your POST requests for placing bids, should also check if the auction end time is in the past before proceeding. If it only checks the status of the auction (opened or closed) it might get auctions that are ended with their status set to opened. The reason is that the cron job might still be processing the auctions and changing their status.
Another similar approach is to create service that runs on operative system level (probably c or c++ app) that would run constantly in the background and do the checks.
The good thing with the first approach is that most of the hosting companies already offer setting up cron jobs. One example is Bluehost.
For setting up windows based "cron jobs" read additional info on this post
I hope this makes it more clear to you how to handle the auctions.