How would I approach this.
My idea is to limit posting with a timer. So for example,
if a user posts a question, the user will have to wait 'X' ammount of time before the user can submit another question.
I am using Meteor as my framework. I am not asking for anyone to write up the code FOR me.
I am studying by myself, and I couldn't find any tutorials/tips on what I approach I should take to accomplish this.
Any references, or pointers would be greatly appreciated!! Thank you!!!
(As of now, I am using a Meteor Method to postInsert into the mogoDB)
In the browser, when the user posts a question, you can disable the controls for posting another question and then use setTimeout(fn, x) to set a timer for x milliseconds from now at which time your fn function can then re-enable the controls to allow them to post again. Ideally, you'd probably also provide some advice on screen about how much remaining time before they can post again.
To prevent a simple browser refresh from re-enabling the controls, you could also store the time when the next post is allowed in a cookie and read that cookie whenever the page is loaded to decide if the posting controls should be enbled or not.
But, since client protections are not entirely secure (they can be bypassed, sometimes even by just opening another browser), you may also want to record the time of last post in the user session on the server whenever a user posts. If a new request to post arrives, you can check the time of the last post and decide if enough time has elapsed to allow the post or not. This assumes you have some sort of user-identifying information which you can use to know when this user last posted. If not, you would need to add such information.
Related
I am trying to realize booking system on my site. I want to allow user to book terminal entity for 10 minutes. Entirely, flow is enough big and goes over several pages.
While user navigate on this flow he should see how many time he has to complete operation.
Please advice me how to realize cross page timer.
I think the most straightforward way would be to create a cookie or an item in the user's localStorage which contains the start time of the transaction. Upon loading the page, you check for the existence of this value and compare it to the current time, if it exists.
You can use setTimeout or setInterval to run timers in the browser. However, a browser window is not guaranteed to continue to execute when it is not active. If the user hides the browser or goes to another application, the application cannot be sure that the timer is still running.
There is a newer specification for threading called web workers, which may help to alleviate the setTimeout problem.
https://developer.mozilla.org/en-US/docs/Web/API/Worker
As an alternative, I would suggest to store the start time on the server and continuously check the current time against it with polling HTTP requests. Or maybe just check it before they submit.
Or as stated by #sholanozie, store it in a browser cookie and just keep checking that.
I'm trying to guess how much time a user expend on my website in php. To do that, i was thinking that for every new action on my web, i could get the difference between the $_SERVER['REQUEST_TIME'] and the current.
I would also be planning to get stats of my current hosting but i don't know if i can get these values via PHP request.
I would like to get your point of view about using this first and second method, but in advice I should say i'm not really happy with the first option, cause server could be collapsed if the amount of petitions are really high..., otherwise I don't know any other way so if you could help me, it would be wonderful.
On my website i'm using HTML5, CSS3, PHP, JavaScript, JQuery, AJAX and MySQL database.
It is supposed i'd like to store and count all the time users stay logged in my webpage.
Thanks in advice.
There are a few ways of doing this, but only one way to get fairly accurate readings.
PHP Time Difference
This method is what you were talking about with checking the time difference. You would mark the time the user visited the page. Then when the visitor navigates to another page, you subtract the two times and you have the duration the user was looking at the previous page.
To hopefully make myself a little more clear, below is a basic layout of the actions you need to perform to make the PHP time difference method work.
Log the current page URL and time(). Store this as a cookie / session / entry in the database.
When the user visits a page, check the HTTP_REFERER variable and if it matches the page they were previously on, you can calculate the time they were on the last page. The referral check is needed to make sure they are not just opening a new tab and visiting your site again. You will also want to add a time limit so if the value is over 30 minutes it doesn't mark them as visiting the page for over 30 minutes.
Keep repeating those actions and you will have a somewhat okay tracking method. This won't be that specific and in some cases not work if they don't send the referral header.
Javascript Tracking
You can send a "heatbeat" or a "ping" every few minutes to tell your server that the user is still on a specific page. You would want to send the URL the user is currently on as a parameter, don't rely on the HTTP Referral header to be sent. Using this method you can get very accurate readings. You could even track if the user is focused on the web browser window or not to check if the page is being read or just in the background.
I'm looking for an event that will return when close page whether the user is connected to my site.
onbeforeunload does not help me because it is also activated in efresh, submit, browse from page to page on the same site.
There is no client side event that triggers when a user leaves your site for another site specifically.
If you want to know if users are online you can make repeated ajax calls on a timer, and use a server side session that updates a timestamp of the last request. Using this you can query the timestamps for example, get sessions where the timestamp is in the last 2 minutes.
If polling is an option and you have a server-side backend, you could make a keep-alive script polling the server every x seconds and add it to all pages on your site. If you do not receive enough calls (i suggest at least 3 or so), consider it as a signal the user has logged out. Of course this won't provide an immediate feedback, but should be reliable enough.
End users are often told not to hit the submit button twice, allowing the transaction to complete; and, there are different techniques used to address this situation.
Recently though, someone asked me, "what do you do to handle the situation of a user doing a page refresh after doing a submit", the implication being that this will cause a double submit or other problem.
Can you let me know if this is a real problem that needs to be handled ... what the situation is and how to best resolve it, if at all.
The best way to resolve this is using the Post/Redirect/Get pattern.
Yes, this is a real problem unless you handle on your side. In practice on most browsers when the user hits refresh the data is resubmitted and if you on the server side do not check for this it would result in you taking the same action twice (e.g. charging a credit card twice, duplicate forum post et.c.).
The way to handle this is to check whether the user has previously done a post. For example, if you are building a forum you would send a hidden variable with a unique ID with the post. As you parse the posted data you save this unique ID into your database. If you ever encounter a post with a unique ID that has already been saved you know that you are looking at a "refresh" on the client side and you simply disregard the post.
Hope this helps!
If your users are so inclined to do a page refresh, it sounds like you have a service taking way too long to respond. Disable the submit button on submit, and show some kind of loading indicator until the response comes back.
Alternatively, respond immediately on the server and queue the action for later. Linode, for example, queues server behavior, rather than running immediately on "request to resize partition". You can generalize this approach for other behavior, and even show things like progress indicators and the like with ajax.
Yes, it can be a problem (and actually is a problem in a lot of websites).
But I think this is more of a server side related question than Javascript.
Best practice is to use Post/Redirect/Get pattern (since you are asking specific about refresh after submit).
Yes it is a real problem but I believe this is typically handled by the browser. Chrome for instance will notify you on page refresh if there will be data posted to the server as a result, and give you the option of continuing or aborting.
EDIT:
Actually... come to think of it I did have to deal with this at work. What I ended up doing was creating a shadow box over the page untill the process was complete to
give visual feedback that the process was working and
Prevent any other user actions.
"what do you do to handle the situation of a user doing a page refresh after doing a submit"
You should redirect to the page after a form is succesfully submitted.
This would prevent that the user submits the data again and prevents that anoying alert of the browser saying the data will be submitted again.
I know a few sites (such as my bank and my school) that kill a session after their has been idle for a set amount of time. It is my understanding that session activity is determined by users following links or at the very least from some kind of active interaction, like updating a form via ajax. Basically the server gets a request to do something during the session and goes ahead and extends the session time another 15 minutes.
But on some occasions I have lost major amounts of time and info while filling out a text box or reading some long set of instructions along the way.
So why not have an ajax script that listens for keyboard activity and mouse movement and lets the server know that the user is still there and active, even if they aren't clicking a submit button or following a link?
I was wondering if anyone knew of respectable sites that already do this, or if I was overlooking some major security hazard with this idea.
The only thing I can imagine would be risky are the random acts of cats, vibrating electronics nearby, or a hyper child.
But in all of the above, the user is most likely at home and -- unless they are trying to get exploited -- have probably minimized the window and thus these things are very unlikely to trigger as an event.
Does anybody see any other major risks?
Typical AJAX sites are making posts back to the server anyway. These events are renewing the users session already.
If you put these events on keyboard or mouse clicks, how many times are you going to be posting to the server? If I am typing in a form field like I am now, that means you could potentially have a ping to the server for each letter I type; not a very efficient solution. On the other end, what if your user is just sitting their reading or using an external text editor to type their text into and will copy it into your form later.
I think the more typical solution to provide a friendly UI so that long posts do not get dropped because of a session expiration is to use an auto-save feature. Google Docs does this. Every few seconds/minutes, they post the contents of the editor back to the server without the user actually clicking save/submit. The other option is to inform the user that their session is about to expire (could be done with a javascript timeout). Provide a link to ping the server to renew the session.
Your solution lends itself to the same problem: you are relying on user behavior. In the first case, navigating between pages and in the second, mouse clicks.
I used to work for a company that did a lot of online contests where users would have to enter essay content as well as shorter blocks of data; we used to modify the session time out "session.setMaxInactiveInterval()" for the user's session when they hit the "long-winded" page so that they would have more time to edit, and then we would set it back to normal after the submit.
Later at that company and a couple others I worked at I proposed a solution similar to what you are describing, but for various reasons it was never accepted. It was never considered a bad idea, just not one we chose. Basically it was going to be an ajax call on a timer so that just before the session timed out, it would fire off a light-weight ajax "ping" and keep the session alive as long as that page was open. I have never had the chance to implement it in the "real world" so perhaps there are negatives that I have not thought of.
Good luck.