I have a flash element in a page that load a chart based on some complex queries that can take up to a minute to load. I call the query with this code :
var chartData:URLLoader = new URLLoader();
chartData.addEventListener(Event.COMPLETE, onLoaded);
chartData.addEventListener("httpStatus", onHttpStatus);
chartData.load(new URLRequest(chartURL));
I listen for the complete event or any server error event.
My problem is when a user want to go on another page while the flash is loading the URL : the browser is waiting for the url to be fully loaded before accepting the request of the user. As I say this chart can take up to a minute to load and it's kind of annoying for my users to wait if they want to change page.
Here is my question : Is there is an event to listen any event from the browser (click on another link, click on the "back" button of the browser...) ? If I'm wrong in my way to do this don't hesitate to tell me, I'm not really used to program in flash.
Thank you.
I think I understand what you're describing. Some things you might want to try out:
File Upload HTTP Server
If the files are very large, you might want to load them on another HTTP server, like Nginx. Check out the Nginx Upload Module (I'm sure Apache has the same thing). That basically allows you to upload files without making the user feel the impact at all.
The only problem with this is that it's pretty complex, and you won't know when the file is done uploading. But they do have examples of how to show Upload Progress Bars with Nginx using Javascript, so you could do something like that, and on completion (in javascript), send a message to flash that invokes something like your Event.COMPLETE handler.
Browser Events
There are browser events to intercept with Javascript to prevent your user from leaving the page until the download has completed (not recommended as it may annoy the user):
onexit
onclose
onblur (when they click somewhere else)
Check out this example: Javascript onclose: Warn the User.
Hope that helps,
Lance
Related
In my web page there is the following measurement
const data = {
event: "FreeTrial-RegistrationLoginDone",
eventContext: "additional info"
};
window.dataLayer.push(data);
The issue is, I need to redirect from this page right after this measurement and there is a several second delay between pushing into window.dataLayer and automatic calling the API endpoint /collect. The web page cannot wait this long. Is there an option to prompt GTM to call /collect immediately?
Quick answer: yes, you can do it. You can tell analytics.js library to send the request "syncly", right when it's called. This is achieved by setting the field called transport to the value beacon in your GTM tag. You can find more on it here: https://www.simoahava.com/analytics/fire-trigger-when-user-about-to-leave-page/
Normally this happens on success, right before the redirection to the thank you page. What we normally do here is ask the developers to move this push to the next page and make sure it doesn't fire on reloads or direct hits to the thankyou page.
Also, GA4 introduces certain batching logic where it delays the calls to try to consolidate multiple events in one network request. This delaying logic, however, should use the onbeforeunload or a similar callback to make sure they still send the request even if the page is navigated from. I would suggest first debugging this screen transition and checking your Network tab to make sure that the collect request is indeed being lost on redirect.
I am using asp.net and Ajax functionalities to make requests to server via web services for a search functionality. On click of search button, I am making the screen inactive by displaying a loading image over it. The issue is some searches takes longer time, and the user is forced to wait till the results are fetched. Is there any way the search can be cancelled manually, like a button click while the search is being performed by the server.
Any help or alternates will be appreciated.
One thing you can try is to set timeout on your ajax call, take a look here:asp-net-page-webmethod-ajax-call-request-timed-out
Another thing is to use javascript setTimeOut to display the user a message after a few seconds saying "its taking too long. wait for results or Abort?" where the "Abort" is a link that refreshes the page.
I am able to download a file from my server when a user clicks a button in the on clicked event handler, but I have to first create the file on the server with a service call. In my on success method I can then download the file for the user. When I do this, however, I get the following error
Error: Error #2176: Certain actions, such as those that display a pop-up window, may only be invoked upon user interaction, for example by a mouse click or button press.
I think I understand the error in that the download pop up window can only be invoked from a user interaction. How can I work around this. I am doing it in response to a user interaction, but I cannot execute the download until after the server has created the file.
The reason that functionality is there is for security purposes. I would say there is no way to "Get around this"; but you can consider alternate implementations. Here are a few:
1) Give the user an interface. The first button click says "preparing file for download" and the when you get the resource back; change the button to "download now". That way you force user interaction for the download.
2) Immediately launch a URL to the server side template that will generate the file and return it. If the process is relatively quick the user probably won't care.
3) Switch to an AIR app which does not include as many restrictions in access to the local file system.
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>
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();
}
}