Why session_end event is not getting called when we close a browser ?
Because the session doesn't end when the browser is closed. The session ends when it's timed out, or it is explicitly ended, server-side.
The browser closing really has nothing to do with the connection to the server. The connection is already over, once the page is fully loaded (excluding some funky ajax).
Silky has right, but you can try call ajax oneway method binded to onbeforeunload event and on server you can handle this event. But it'll be probably not very reliable and works not in all browsers.
<body onbeforeunload="ClosingWindowAjaxEventHandler();">
Related
Is there any possibility of "listening" to the state of GET SiteCatalyst image requests ?
I'd like to run a callback function only when the requests are over, to be more clear when they receive the 200 status code and I'm sure they're done.I'm confident no "built-in" method is available and maybe I should hack the core s.track.s.t() function...?Thanks a lot.
You are right, there is no global "built-in" callback method for when the Adobe Analytics request is complete.
A couple notes I should mention to you about attempting to hack the core code:
1) If you are using the AppMeasurement library version 1.4.1+, in some circumstances, a POST request may be made instead of an image request.
2) Responses that are not 200/OK or otherwise completed/successful does not necessarily mean the data failed to be sent to Adobe. Most common scenario is a NS_BINDING_ABORTED error returned.
The main bad effect I'm getting here is what I previously thought as a double XHR request.
It wasn't. In reality the first request gets redirected as it would be the first visit of a new visitor (302 status) and a new visitorID is brought down by Adobe server.
Then the redirected "200 status" request is made with this new visitorID within.This is bad because every XHR requests would result in a new visit of a new visitor even though a previously set "s_vi" cookie is there in browser, with the lack of previous collected data for that user.I know what XHR redirects couldn't be blocked so I'm wondering if there is a way to "tell" Adobe server it's not the first request ever made, in order to stop the redirect and do not use a new visitorID.
I am working on an Eclipse RAP application (RCP as web application). After the servlet container has invalidated the HttpSession (session timeout, setMaxInactiveInterval exceeded) the following exception is thrown when clicking on the application in the browser:
java.lang.NullPointerException
at org.eclipse.rap.rwt.internal.service.LifeCycleServiceHandler.service(LifeCycleServiceHandler.java:66)
at org.eclipse.rap.rwt.engine.RWTServlet.handleValidRequest(RWTServlet.java:135)
...
So I implemented a javax.servlet.Filter that detects the situation and should now redirect somewhere to display a "session timeout, please reload" message.
My preferred solution for the "session timeout" warning would be a simple HTML5 page with a link back to the application. But I don't know how to integrate HTML5 pages with a RAP application (and whether that is a good idea to start with). Also I am not clear how and where the redirect should happen.
For redirecting I tried two variations in the Filter.
The first one gives me "Error: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data":
httpServletResponse.sendRedirect("/myapp");
And this one "java.lang.IllegalStateException: Invalid thread access
at org.eclipse.rap.rwt.RWT.checkContext(RWT.java:704)"
UrlLauncher launcher = RWT.getClient().getService(UrlLauncher.class);
launcher.openURL("http://www.eclipse.org/");
So I am probably really going down the wrong path here...
Does anybody know of a standard way to deal with HTTP session timeout situations in an Eclipse RAP application?
Is the HTTP session the correct place to deal with this or should I be looking at org.eclipse.rap.rwt.service.UISession, or something else?
How can I redirect to the home of the application if it lives on an URL like "http://127.0.0.1:50045/myapp"?
Can I easily integrate simple HTML5 pages with a RAP application (pages in same Eclipse project, deployed in same WAR, available on same host)? Or will this be a tedious task that does not come out of the box?
First off, a NullPointerException should never happen during normal operations, please file a bug including the RAP version and a stacktrace.
Just a guess, the problem may be caused by invalidating the session from within the request processing. If this is the case, it may help to use the HttpSession method setMaxInactiveInterval with a small timeout instead.
The problem with redirects is that a RAP application sends background (a.k.a. Ajax) requests to the server and expects JSON responses in return. If your filter redirects to some other page, the RAP client receives an HTML page instead of JSON. In order to redirect the browser to another page, you should send a JSON response to the client that includes this redirect (see bug 388249):
{"head": {"redirect": "http://www.myurl.com/"}}
To integrate other HTML5 pages in your RAP application, consider the Browser widget.
System.exit(0) if you want termination to be fluid - then modify your application specific shutdown hooks/exit code response to notify as you please.
Java based RAP/RCP:
try{
HttpSessionCollector.terminationQueue.remove(RWT.getUISession().getId());
RWT.getUISession().getHttpSession().invalidate();
System.exit(0);
}catch(Exception ex){
ex.printStackTrace();
System.out.println("failed to terminate session. adding user back to sessions list");
HttpSessionCollector.add();
}
I have developed one application and facing issue with security stuff.
My application is running in doPost method which doesn't explicit the URL in browser. If I'm trying to change the doPost to doGet (using webdeveloper tools-->Forms), my application's URL will be displaying explicitly. So I need to throw an error/stop app response, If user tries to change the forms from doPost to doGet ?
I suppose the question here is: Why do you regard it as a security issue, that the URL might be displayed in the browser?
In case you don't want the user to have access to the URL or other request data, you probably have fundamental design problem, as the user can track the post request using the developer tools.
In case you don't want somebody else than the user to see the URL and thus think it should not be displayed in the browser, I would not worry, as the user has to actively and consciously "mess" with your application to achieve this behavior.
In general it is probably a good idea to throw errors and prevent the request from being processed if your front end does not behave as expected.
I have an Android application which makes requests to my webserver via both a WebView and an HttpClient. I sync cookies between the two using a CookieSyncManager. So far, so good.
When my application starts (inside onResume()), I run a piece of logic similar to the following:
if ( appHasBeenIdleFor30Minutes() ) {
CookieManager cookieManager = CookieManager.getInstance();
cookieManager.removeSessionCookie();
CookieSyncManager.getInstance().sync();
}
This correctly resets any session cookies that were set from the user's previous session. My question is: will this behavior happen periodically on its own? This question (android webview or browser not deleting session cookies on device reboot) seems to suggest that it does not. When I use the cookie-sync'd HttpClient via a Service it appears that session cookies are not cleared, thus resulting in strange server-side behavior.
I've been unable to find concrete documentation on the lifecycle of session cookies (expiration time=0) inside a WebView/CookieSyncManager - has anyone else had more luck?
I received a response directly from a Google engineer, who confirmed my suspicions:
You are correct, session cookies do not expire automatically in the
lifecycle of a WebView.
If you are seeing issues with this, you can always clear all of your
cookies or overwrite your session cookies explicitly with an empty value.
The code you have suggested looks like a good workaround, just be aware
that cookie synchronisation using a CookieSyncManager is not synchronous -
the startSync(), stopSync() and sync() commands are executed
asynchronously in a background thread.
TL;DR - session cookies do not expire when a WebView closes, you'll have to manage that yourself.
Why does using Fiddler break my site sometimes on page transitions.
After a server side redirect -- in the http response (as found in Fiddler) I get this:
Object moved
Object moved to here.
The site is an ASP.NET 1.1 / VB.NET 1.1 [sic] site.
Why doesnt Fiddler just go there for me? i dont get it.
I'm fine with this issue when developing but I'm worried that other proxy servers might cause this issue for 'real customers'. Im not even clear exactly what is going on.
That's actually what Response.Redirect does. It sends a 302 - Object moved response to the user-agent. The user-agent then automatically goes to the URL specified in the 302 response. If you need a real server-side redirect without round-tripping to the client, try Server.Transfer.
If you merely constructed the request using the request builder, you're not going to see Fiddler automatically follow the returned redirect.
In contrast, if you are using IE or another browser, it will generally check the redirect header and follow it.
For IE specifically, I believe there's a timing corner case where the browser will fail to follow the redirect in obscure situations. You can often fix this by clicking Tools / Fiddler Options, and enabling both the "Server" and "Client" socket reuse settings.
Thanks user15310, it works with Server.Transfer
Server.Transfer("newpage.aspx", true);
Firstly, transferring to another page using Server.Transfer conserves server resources. Instead of telling the browser to redirect, it simply changes the "focus" on the Web server and transfers the request. This means you don't get quite as many HTTP requests coming through, which therefore eases the pressure on your Web server and makes your applications run faster.
But watch out: because the "transfer" process can work on only those sites running on the server, you can't use Server.Transfer to send the user to an external site. Only Response.Redirect can do that.
Secondly, Server.Transfer maintains the original URL in the browser. This can really help streamline data entry techniques, although it may make for confusion when debugging.
That's not all: The Server.Transfer method also has a second parameter—"preserveForm". If you set this to True, using a statement such as Server.Transfer("WebForm2.aspx", True), the existing query string and any form variables will still be available to the page you are transferring to.
Read more here:
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm