I'm building a website with mvc3 and I need to delete a data in my database only when the application is closing. (The user click on the red x).
I tried with javascript using the onbeforeunload event, but this event happens everytime I go into a new page in my application.
Is it possible to detect when the user closes the window?
It's not possible. But, what you can do is have a small javascript block that will make an ajax call every n minutes/seconds to tell the server that the user still has the browser open.
This way, you can set a timeout that says if after 5 minutes we haven't heard from the user we can delete the data in the database (or whatever action you need to do).
To implement the timeout logic there are 2 options:
You have a separate service (console app or windows service) running on some interval that checks if any user's timeout is greater than some value. If it is then perform whatever action you need.
If any user performs an action that would have been blocked, you first check if any user still has it active (the timeout value is greater than current time). If there is, you block the user, if there isn't, you can remove that old timeout value since it's expired.
Use a synchronous ajax request in the window.unload event.
When the user goes to a different page, or closes, or refreshes then this event will fire. You could call a service on your web app to notify it that the user is no longer editing the document
After a very quick google, I saw this snippet here
$(window).unload(function() {
$.ajax({
url: 'resetTheDocument?id=whatever',
async: false,
cache: false,
type: "POST",
data: "My work here is done"
});
});
Good morning you could try adding your logic to the global.asax file in the Session_End method to delete the record in your database.
Related
We are seeing a change in Outlook with one of actions (“Help”) that stopped working on the web client only.
This action simply calls a js that opens a web page in a displayDialog() but it’s uiless in the sense that there’s no pane.
The other action (“Sign”) works ok but it launches a pane that does this.
Both of them work fine on the rich client (at least the version I use).
I wonder if there has been in recent changes in the requirements or the way this works?
We’re not seeing any error messages, just nothing happens after the prompt saying that the add-in is doing something.
We did some initial testing and noticed that in chrome the dialog will sometimes appear briefly. Could you confirm that you are calling event.completed() in the eventhandler of EventType.DialogEventReceived? event.completed() must be called in the DialogEventReceived handler otherwise the dialog will be closed prematurely.
Office.context.ui.displayDialogAsync(url, dialogOptions, function(result) {
// In the callback, save the dialog object
dialog = result.value;
// Add an event handler for messages sent via messageParent
dialog.addEventHandler(Microsoft.Office.WebExtension.EventType.DialogMessageReceived, receiveMessage);
// Add an event handler for events from the platform (like closing the dialog, etc.)
dialog.addEventHandler(Microsoft.Office.WebExtension.EventType.DialogEventReceived, dialogClosed);
});
Our application has been developed on Liferay with multiple Spring MVC portlets on the page. Its a single page application, and the navigation only happens inside the portlets. Now sometimes when Liferay session times out and I send a request to the control for a new view, the liferay login page is being shown inside the portlet. But the expected behaviour is if the liferay session is timed out, then the whole page should have redirected to Login page.
I have specified following properties in the portal-ext.properties
session.timeout.warning=1
session.timeout.auto.extend=false
session.timeout.redirect.on.expire=true
browser.cache.signed.in.disabled=true
Any suggestions?
If you're just doing Ajax navigation in the portlets, you might want to hook into Liferay's session-extension way (you'd have to look it up - there's a client side timer that counts down and displays the "session.timeout.warning" - I can't give pointers right now)
Alternatively, if a session extension is acceptable as long as a browser window is open, you can use the same mechanism to show an alternative behaviour: Instead of willingly timing out a session, it can extend the session. See portal(-ext).properties:
#
# Set the auto-extend mode to true to avoid having to ask the user whether
# to extend the session or not. Instead it will be automatically extended.
# The purpose of this mode is to keep the session open as long as the user
# browser is open and with a portal page loaded. It is recommended to use
# this setting along with a smaller "session.timeout", such as 5 minutes for
# better performance.
#
session.timeout.auto.extend=true
Does this happen in all your pages or only on specific pages. ?
Does this happen on click of any button?
If so , do the following in the method that you are calling on the click of the button,
function onClickFunction(){
var liferaySession = Liferay.Session._currentTime;
if(liferaySession == '0'){
//reload page
}
else{
//proceed
}
}
I have long poll Ajax request. Browser, at least but not last IE doesn't terminate the request at page leaving, so request remains open and active even if a user visits some other site. Say more, a browser can successfully process responses from this connection, although their result go nowhere. General recommendations as call htmlxml connection abort or stop for a window obviously do not work.
So my implementation is adding extra Ajax call on unload to notify server connection holder that page is on leave, so it can send some dummy response and a browser will return the connection to pool of available after. This approach works but looks for me over engineered. Unfortunately I can observe a similar problem with some other programs, like GMAIL, it also does long poll and as result after some reloading it stops working. So if somebody found some good approach to address the problem without switching to short poll or assign connection timeout, then share your solution.
There's an abort() method on IE's XHR which will manually disconnect it.
It's a bit hacky, but you could try something like:
<body onbeforeunload="AbortMyAjax()">
and use that method to abort any active long-polls.
For reference, here's a bit of code from a project of mine:
$this.lp = null;
function _LongPoll() {
$.ajaxSetup({ cache: false });
$this.lp = $.getJSON(m_PollUrl, _LongPollCallback);
}
And in the body beforeunload:
if(!!QueueManager.lp && !!QueueManager.lp.abort) QueueManager.lp.abort('PAGE_CLOSED');
I having an issue with FB.ui permissions.request window.
FB.ui({
method: 'permissions.request',
perms: 'publish_actions',
display: 'popup'
},function(response) {
// This function is never called ? });
Context :
I use the new OAuth window (with timeline), i have configured my apps to work with it.
I'm french and use Facebook in French.
First issue :
- My callback function is never called ...
Second issue :
- The new OAuth window, seem to be not the good window.
It's called 'permission request' but inside it is the copy of login window. And no permission request is displayed.
So, my question is : how can i do the permission request in js ?
How displaying this window : https://developers.facebook.com/attachment/app_extended_perms.png/ ?
Thanks.
The reason you are not seeing it is because the application process has become a two step process.
Being that the person accepts to login into your application.
Being the person accept your extended permission which is where the callback url comes into play.
Documentation can be found here.
So the reason your callback isn't being called is because the two step process. I would suggest making the response attached to second page that is called.
I am not sure how the JS SDK works but it is how I managed to do it.
Goodluck.
Disable "Enhanced Auth Dialog" in your app's advance settings and see if it works. If you want to stick with Enhanced Auth Dialog then checkout Setup Auth Dialog Preview for Authenticating user section of this tutorial.
This is a weird bug, and I'm not even sure how to begin figuring out what's going on.
We are using Cake 1.3.8 with our sessions in the database. I am not using ACL or any other access control. If we navigate into the application and click around a bit, and then rapidly click the browser back button twice (I've tried in Firefox and Chrome) the user is logged out more often than not and receives the error message 'You are not authorized to access that location'.
All of my searches thus far have involved people wanting to make the page inaccessible if a user logged out and then used the back button. I'm not seeing anything reported with regards to the issue I'm seeing.
Does anybody know if this is a Cake issue or have any thoughts on debugging what is going wrong?
Update: I found where the problem is. I have the security set to high, because we need the session to be closed whenever somebody closes the browser. I also have the timeout set very high because we do large binary uploads to S3, and don't want the user logged out while it's uploading or downloading. The specific block of code in cake_sessions.php that's causing the problem is:
$time = $this->read('Config.time');
$this->write('Config.time', $this->sessionTime);
if (Configure::read('Security.level') === 'high') {
$check = $this->read('Config.timeout');
$check -= 1;
$this->write('Config.timeout', $check);
if (time() > ($time - (Security::inactiveMins() * Configure::read('Session.timeout')) + 2) || $check < 1) {
$this->renew();
$this->write('Config.timeout', 10);
}
}
$this->valid = true;
I would guess this is because session IDs are regenerated between requests when security = high. Source:
http://book.cakephp.org/compare/44/CakePHP-Core-Configuration-Variables/cakephp/cakephp1x
You only need one out of sync request, say for a missing image and you will lose the session. I've generally found it unworkable because it's not possible to prevent users double-clicking on links and buttons and invalidating their session.
I would think about using medium security, setting the session timeout fairly short and using an AJAX script to refresh the session at regular intervals (eg every 60s). That way the user will be logged out quickly if the tab/window is closed.
If security is a priority I would suggest hacking the core to make sure the session cookies are set to http_only to help guard against session hijacking by XSS attacks. Cakephp 1.x supports PHP4 so probably isn't setting this by default.
http://php.net/manual/en/function.setcookie.php
It's possible that the session is erased and before it can be written again, the back button is clicked removing the auth from the session variables.
Page loads -> Back Button Clicks -> sessions is erased (but before session is rewritten) -> Back button clicks -> Session checks no existing session.
The only thing that I can think is happening is that when you're going back a page too quickly your code can't validate the person quickly enough (round trip from checking credentials) and throws an error that gets displayed on the next page that is loaded (second backed-to page).
Are you sure the person is actually logged out, or is it just the error being thrown?
Without seeing any code, it will be difficult to nail it down any further.