I want to clear session when browser window closed. But when i am trying to use window.unload event, it triggers also when back button clicked. How can i avoid it?. And clear session on window close.
The other posters are correct. There is a reason you see the following setup on 99% of sites.
Offer the users a logout button to close the session.
Otherwise time out the session after they have been inactive for 1+ hours depending on your paranoia level.
Unfortunately clearing the session on unload() is not a good way to do it. In fact that unload handler will even fire when they go to other pages on YOUR SITE. I highly doubt this is the approach you want to go with.
There is no way to do this that I know of. It would be a security issue if you were able to tell when someone is leaving your page for another or closing the browser.
As far as your page's security model is concerned once someone is off your page there's no telling what's happening anymore
The only way to know if someone has left your site is if... they stop loading pages.
You're best bet is to track a "Last Impression" time in the session in your server application. Update it to now every time they make a page request. If their Last Impression is ever more than, say, four hours old, you know they left for a while, so invalidate their session and start a new one for them.
Related
This question already has answers here:
Identifying Between Refresh And Close Browser Actions
(13 answers)
Closed 6 years ago.
I am currently looking at the "unload" event of a window to try to determine how the "unload" event was triggered, but am having little success. Is there a way to determine how the javascript event was triggered?
Page Refresh
Back Button (or navigate away from the page)
Closing the Browser
Essentially I need to execute some code only when the browser window is being closed, not refreshed or navigated away from.
Purpose: When a customer does an update of our software, the update will redirect their first Internet request to an offer page. There is a button for a "Do Not Bother" option, but some users will simply close their browser. Upon closing the browser, I need to duplicate the "Do Not Bother" functionality so the user no longer gets redirected to the offer page. Simply attaching to the "unload" event will not work due to the different ways of leaving a page.
No, and if there was it would be browser dependent.
What kind of code are you trying to run when the user closes the page?
Is it to logout the user?
Then the user would not be logged out if the browser crashes or the network connection breaks (and probably not if the computer goes to sleep/hibernation mode).
If it is for logout-purposes you should probably use a timestamp variable at the server that gets updated with every request (or use a ajax-ping), and logout the user if it hasn't been seen for a specified time.
Update: Found this answer here at stackoverflow.
Yes, there is a solution!
I've designed a solution based on onBeforeUnload+onLoad events, HTML5 local storage and client/server communication. See the details on https://stackoverflow.com/a/13916847/698168.
I use a method of doing keyboard "sniffing", in that it looks for keydown's of "F5", "ctrl+r", "alt-f4", "backspace" and others, and if it finds them flowing through the keyboard event queue, it sets boolean variables appropriately to trap that status... then I use a "onbeforeunload" function handler, which tests against those boolean status variables to decide what to do.
You can even shut down various keyboard strokes (like "ctrl+n" or "F1" for instance) by using preventDefault(), bubbles=false and returnValue=false in your keyboard handling.
This stuff is not for the faint of heart, but its certainly doable with some persistence and lots of cross browser testing!
Is there a way to call a JavaScript when the window closes or the address goes to a completely different site, not just when the page changes? I know I can use onunload, but that seems to trigger when the page changes.
I have an intranet site that I need to keep track of logging in and out. Instead of users always clicking on "Log Out", some of them just close the browser window.
I have an idea. Fire off an AJAX call to some page that "keeps-alive" the current user's session every 30 seconds or so. After a certain time of inactivity (maybe 40 seconds? Make sure it's greater than 30), the server knows the client has become inactive and can log you out. This might seem like overkill, but it's the only way to reliably know when the user is no longer active. Firing off a call when the window is closed might seem like it'd be good, but if the browser crashes or the computer is turned off or something, the call never gets sent anyway.
window.onbeforeunload = function(){
$.ajax({ url : logoutuser?id=xyz,
async : false
});
};
This will work if when trying to close the window..
One other way is to route all your clicks (for links) on your page through your own custom method -
window.location.href = "someurl";
So that way you can sniff where the user tried to navigate to..
For now, unless someone can come up with a better idea, I have the site running in a 100% frame and the onunload script setting on the default page with the frame layout.
I'm looking for the best way to go about "forcing" the user to fill a textarea.
For my work we have a system that keeps track of time spent on a particular "task". Some tasks are required to have a comment while others are optional. At the top of the page there is a timer, a textarea for the comments and a list of different tasks.
So far I have it so when the user tries to stop the timer, it won't stop until the comment is written (if it is required). When the paged is closed while the timer is running, an onbeforeunload function sends an alert warning that the comments aren't filled out and then the "Are you sure you want to leave?" warning pops up.
As far as I can tell there is no way to prevent the user from completely exiting the page. The idea we had was when the user closes the window, have another simple page open that just has a textarea and an instruction telling the user to write a comment. I'm pretty new to JavaScript and web development so I'm not entirely sure the best way to go about this.
Put that text area in a popup or iframe or modal window where you can control its closing.
On these window.close you can call the functions to validate the text area is filled or not.
Am not sure you can put that in a popup or not .but thats the only good way i can think of !!
There is no way to prevent the user from leaving a page.
Built in pop up blockers will also block the system from opening up popup windows onunload. Only way to allow onunload popups is if your system admins can update every browser to add an exception to the browser security settings.
It is impossible to make a web application act like a client application.
Is there a way to force a browser window to always be on top and in focus? I am working on a project that I need to have the browser window on top and in focus all the time except when closing the browser window. I have tried a few things through javascript, but have not had any success keeping the window in focus.
I am not trying to do this to be forceful to the user. I am working on a project to implement online testing and I don't want the user to be able to switch away to look up answers on the web.
You will need to install a windows application on the clients machine which will force the browser to be on top. This is the only way.
If you are using IE, you can open a Modal dialog which will always be on top and in focus but only while in that browser session, the user is free to switch applications.
Edit: If you are writing a testing application, you are honestly better off just putting a reasonable time limit on each question. trying to prevent them from looking up the answers is worthless. What if they have two machines side by side? What if they have their buddy next to them helping with the answers. You are going to have to go with the honor system on this one.
This is not possible, as the application level focus is handled by the Windows operating system.
You would need to alter the operating system in order to achieve this functionality.
I commented on the question, but realized this is worth posting as an answer...
Find another solution. Think a little about it. If a user is off looking at answers in another window/tab/browser, what would be the side-effects of that? Detect those side-effects, and penalize/block in those cases.
For instance, you can detect the blur event on the window and then poll for activity (focus, click, mousemove, keypress and so on) to determine "idle" time for the user. If the user is "idle" long enough to have gone elsewhere to find an answer, they are more than likely "cheating". You can otherwise simply impose time constraints on questions, and skip those questions if the time allotted runs out.
You can't guarantee that your user is not "cheating". Either construct the "physical" rules of the test such that the chance of "cheating" is minimized, or construct the test itself so that "cheating" is less consequential. Do not try to circumvent in-built user protections in browsers that disallow users from operating their browser as they would any other application.
The browser window belongs to the browser, not to you. Don't screw around with it.
Don't do it, that is, unless you wrote the browser.
It once took me 15 minutes to create a reasonable web browser by using the Windows Forms WebBrowser control. I suggest you require the students to view your site through this custom browser program. Since this program really will be yours, you can force it to stay on top, or anything else you like.
JavaScript has the capabilities do this but it is disabled by default in most modern webbrowsers (And, as you would surely agree, there was a good reason for that!)
This question already has answers here:
Identifying Between Refresh And Close Browser Actions
(13 answers)
Closed 6 years ago.
I am currently looking at the "unload" event of a window to try to determine how the "unload" event was triggered, but am having little success. Is there a way to determine how the javascript event was triggered?
Page Refresh
Back Button (or navigate away from the page)
Closing the Browser
Essentially I need to execute some code only when the browser window is being closed, not refreshed or navigated away from.
Purpose: When a customer does an update of our software, the update will redirect their first Internet request to an offer page. There is a button for a "Do Not Bother" option, but some users will simply close their browser. Upon closing the browser, I need to duplicate the "Do Not Bother" functionality so the user no longer gets redirected to the offer page. Simply attaching to the "unload" event will not work due to the different ways of leaving a page.
No, and if there was it would be browser dependent.
What kind of code are you trying to run when the user closes the page?
Is it to logout the user?
Then the user would not be logged out if the browser crashes or the network connection breaks (and probably not if the computer goes to sleep/hibernation mode).
If it is for logout-purposes you should probably use a timestamp variable at the server that gets updated with every request (or use a ajax-ping), and logout the user if it hasn't been seen for a specified time.
Update: Found this answer here at stackoverflow.
Yes, there is a solution!
I've designed a solution based on onBeforeUnload+onLoad events, HTML5 local storage and client/server communication. See the details on https://stackoverflow.com/a/13916847/698168.
I use a method of doing keyboard "sniffing", in that it looks for keydown's of "F5", "ctrl+r", "alt-f4", "backspace" and others, and if it finds them flowing through the keyboard event queue, it sets boolean variables appropriately to trap that status... then I use a "onbeforeunload" function handler, which tests against those boolean status variables to decide what to do.
You can even shut down various keyboard strokes (like "ctrl+n" or "F1" for instance) by using preventDefault(), bubbles=false and returnValue=false in your keyboard handling.
This stuff is not for the faint of heart, but its certainly doable with some persistence and lots of cross browser testing!