I want to perform some clean-up in my ASP.NET web application when the user closes the IE window or the tab page in which the page is open.
I was looking at the unload event of the "body" element, however the unload event also gets fired when you click the Refresh button in IE or change the URL by typing in the address bar.
Any ideas on which event to catch to trap IE window (6.0 and 7.0) and Tab closing?
use InProc sessions, and the Session_End event in global.ascx to do your cleanup. javascript is too unreliable for this.
Javascript will be unreliable/quite restricting on this for security reasons. It really depends what you are trying to do, if you are trying to fire some code on the clients machine then this is going to be difficult/impossible (which is a good thing, I don't really want websites I don't trust messing with my browser on one of it's most core features, closing a window).
If you want to run some server side scripts to flag the user as gone, again, hard/impossible, as Jasper mentioned global.ascx will go some way as to helping you, but otherwise you will have to have timers and events fired on 'expired' users.
Related
I keep getting reports from users on Safari that my webpage is automatically reloading itself about once per minute, while they're using the page.
My page doesn't do any history state modification, it doesn't use location.reload(), and it doesn't use a crazy amount of memory.
I know Safari might unload background tabs when it runs low on memory. What else can I do to troubleshoot why a browser reloads my page?
Is there anything in the beforeunload event that could help me identify the "source" of these reloads? Or is there some sort of response from an asynchronous fetch() call that would trigger a browser to reload a web page?
Is it possible to detect in Flex application browser window close event so that an action can be
started when user closes Flex application, does anyone know how to do that if it's possible in the
first place? The reason why i am asking this is because i have a multiuser Flex application where
every user has it's own directory on a server side. Application has logout button which triggers
cleanup of user's directory but what if the user just closes the window? I would like to be able
to lunch that same cleanup upon browser close window
In the page hosting your app, write a Javascript function triggered by window.onbeforeunload, and this function can call a function inside your Flex application.
Note that the onbeforeunload function is not guaranteed to work for all browsers.
I would not recommend that approach because the closing action fails too often, meaning worthless. My browser freezes and force-quitted several times a day. My computer sometimes freezes. My internet connection sometimes dies. I think, some browsers even do not guarantee those kinds of actions executed every time.
So, the session timeout might be one safe way in most cases.
You can also try having a socket connection, so that your server can ping if a user is alive and also can detect if socket is closed. Even socket, however, can be unresponsive or can be disconnected sometimes while user is still using the application.
You might want to be strategic.
Is there a way to "disable" the browser's back button after loggin out?
I've read several posts and now I know, that I can disable caching.
( e.g. ASP.NET authentication login and logout with browser back button )
This is working, but I want to disable the back button for security reasons only after logging out (= when there's no Session available anymore).
If I disable caching, the user cannot use the browser's back button while logged in.
I'm using a custom authentication, not the standard of asp.net
Is there a secure (= no javascript) possibility to do this?
As I'm sure you already know, you can't directly disable the "back" button on a browser.
The only methods for preventing a user from going back rely on either setting the page to cache, or involve the use of javascript. Based on the fact that neither of these work for you, there isn't a solution to manage this. I've looked at many articles over the years, and re-searched this several times, and all of the suggestions either use client-side script or the cache.
My best suggestion in your case is to use the cache disable method, and look at how your UI responds to the "back" button and see if there are changes you can make to the design to make it smoother. This may involve checking the session variables, or checking to see if the user is still authenticated, but given your requirements, I believe you're out of luck.
In short, you're going to need to choose the lesser of two evils.
Using the page cache will ensure that people can't use the "back" button at all without using javascript - presumably better security
Using the javascript to delete page history on logout will allow you to prevent users from going back after logged out, but someon ewith noscript turned on, or someone malicious can disable your control.
You didn't specify exactly who you are trying to protect, and from what, but if I'm guessing right, and you're concerned about the user who leaves their PC after logging out, but without closing the browser window, then is the Javascript really a concern?
Thinking it through,the type of person who would do this isn't thinking about how the info can be used maliciously. Someone who is malicious, presumably, is already "thinking like a bad guy" and knows enough to close the browser window.
Either option could be bypassed via malware that intercepts/alters the http headers, javascript, etc, so neither is really 100% effective. The only difference I see is that the javascript option can be broken both by altering the html as it travels across the wire (using something like Fiddler or malware) AND by simply having Javascript disabled. so the page cache option is marginally better for security purposes.
Using https instead of plain http offers a lot more protection in combination with the header method, making it much more effective, because it greatly increases the difficulty of manipulating the data across the wire, and it's not disabled simply by disabling JavaScript.
Either way, I think you need to weigh your options and choose one or the other. As sad as it seems, we can only do so much to protect the users from themselves.
Anything running on the browser can be intercepted and/or disabled. Any page sent to the client-side can be saved: any link URLs, content, javascript, etc.
If you let me load a webpage in a browser on my machine, I can view and save the source of every page I see, and capture every piece of communication to and from the server. If you want HTML to render or javascript to run on my machine, I get to see it and keep it forever if i want.
You could control this by only permitting access to your application through a remote connection to a controlled machine where the application runs, but for a consumer app, this is probably prohibitive.
you could however, discourage most users with something like this
function logout(){
window.open(loggedOutPageURL)
self.close ()
}
a malicious user will have no problem disabling this javascript, or just saving content as he receives it, but this might be the best you can do.
abandon method for dispose the session on logout & check Session!=null on your Data or dashboard page then I think there is not need to disable Back button.
write the script below logout button:
<script language="text/javascript">
window.history.forward(1);
</script>
In a page I have multiple update panels that have timers associated with them to refresh the grids. My issue is that when asynchronous request (update panel) is in progress page does not respond. If user try to click some other link to move to some other page he even can not do that until asynchronous request is completed.
Is it not possible that user may able to cl...
Browser runs in a single-threaded mode, you can’t run any background task. If any task is running all other event gets queued up and user will get a impact that browser is hanged or not responding, so for situation like this you need to handle this by yourself.
1- Keep the partial post back light and fast.
2- If possible do it in small steps.
3- Show the progress bar, so that client will not get irritated.
Only one UpdatePanel can postback at a time. If your timer is kicking off multiple requests, the last one will win and cancel the rest.
Workaround:
Simultanious Async Requests Using Multiple Update Panel
We have a scenario in which we like to detect when the user has left our site and immediately expire their .Net session. We're using Forms Authentication. We're not talking about a session timeout, which we already have. We would like to know when a user has browsed away from our site, either via a link, by typing in an address or following a bookmark. If they return to our site, even if right away, they will have to log back in (I understand this is not great usability - this is a security requirement we've been given by our client).
My initial instinct is that this is either not possible, or that any solutions will be extremely unreliable. The only solutions we've come up with are:
Add a JavaScript onBlur event handler that tells the server to log out the session when the user leaves the site.
Once the user has logged in, check the HTTP referrer to ensure that the user has navigated from within the site.
Add AJAX polling back to the server to keep the session refreshed, possibly on a 10-second interval. When the call isn't received on time the session would end.
The onBlur seems like the easiest, but possibly least reliable method - I'm not sure if it would even work. There are also issues with the referrer method, as the user could type in an address within the site and not follow a link. The AJAX method seems like it would work, but it's complicated - I'm not even sure how to handle it on the back-end. I'm thinking there might also be scenarios in which that wouldn't always work.
Any ideas would be appreciated. Thanks.
I have gone for a heartbeat type scenario like you describe above. Either Ajax Polling or an IFRAME. When the user closes the browser and a certain timeout elapses (10 seconds?), then you can log them out.
Another alternative would be to have the site run entirely on AJAX. Thus there is only one "URL" that a user can visit and all content is loaded dynamically. Of course you break all sorts of usability stuff this way, but at least you achieve your goal.
If the user closes their browser, or types in a different URL (including selecting a favourite) there is not much for you to detect.
For links on your site, you could create links that forward via your site (i.e. rather than linking to http://example.com/foo you link to http://mysite.com/forwarder?dest=http://example.com/foo).
Just be careful to only forward to sites you intend to, otherwise you can open up security issues with "universal forwarding" being used for phishing etc..
You absolutely, positively need to tell the client that this is not possible. They are having a basic misunderstanding of how the Web works. Be diplomatic, obviously... hell, it's probably someone else's job... but it needs to be done.
Your suggestions, or a combination of them, may work in a simple proof-of-concept... but they will bring you nothing but support nightmares and will not work consistently enough. Worse, you will undoubtably also create situations where users cannot use the application at all due to the security hacks misfiring on them.
Javascript has an onUnload event, which is triggered when the browser is told to leave the page. You can see this on StackOverflow when you try to press the back button or click a link while editing an answer.
You may use this event to trigger an auto-logoff for your site.
I am unsure, however, if this will handle cases wherein the browser is deliberately closed or the browser process externally terminated (I'm guessing it doesn't happen in the 2nd case).
If all navigation within your site is done through .NET postbacks (no simple html links or javascript open statements), you can do automatic logoff and redirect to the login page if the page load is not a postback. This does not end the session on exit, but it looks like it because it enforces a login if manually navigating to your web app. To get this functionality for all pages, you can use a Master page that does this in the Page_Load.
private void Page_Load(object sender, System.EventArgs e)
{
if (!IsPostBack)
{
System.Web.Security.FormsAuthentication.SignOut();
System.Web.Security.FormsAuthentication.RedirectToLoginPage();
}
}