In my RAP application I need to do some logout handling (forward do keycloak sso/logout).
Where would be a good hook to do that?
org.eclipse.ui.application.WorkbenchAdvisor.postShutdown() is executed also if I refresh my browser window (F5), I don't want the session to logout on-refresh. Rather if the session is expired or the browser window is closed.
Is there a hook for expired sessions or a session invalidation event?
Found UISessionListener.beforeDestroy() but it also is executed on browser-refresh:
RWT.getUISession().addUISessionListener(new UISessionListener() {
#Override
public void beforeDestroy(UISessionEvent event) {
System.out.println("UISessionListener.beforeDestroy" + event);
}
});
Code show that UISessionListener catch the event UISessionEvent that contains
UISession. This object is bound to HttpSession, if you don't wont to expire just configure session to endless(better to make it quit long but not endless depends on amount of users using application).
HttpSession has expiration time by default (for example for apache tomcat it is 30m). But it is configurable. Session expired when not single "touch" of session (request) in such timeout occurs.
Also by default session will "survive" during tab close/open, since cookie saved on client side (again this behaviour configurable).
Related
In our JAVA web application we maintain users' session in a database table active_sessions. And we do not allow multiple sessions per user. what it means is, if you are already logged in with a particular user account, you cannot open a new session with the same account. In case somebody does, we display error 'User already has an active session'. When user clicks on Logout his entry from table active_sessions is removed. But in case where user closes the window without logging out his entry remains in the table active_sessions. So any attempt to login in future results in an error 'User already has an active session'. Any tips on how to destroy user session in database in case he closes the browser window without logging out.
Edit: After reading all the posts it seems there is no clean way to restrict single session per user.
Use the 'onbeforeonload' JavaScript event which can perform an AJAX call to your server to delete the entry. This event will however be executed each time the page is unloaded so if you don't have a SPA then you'll need to ignore the event for href and such.
Agree with Almas however that your approach is dangerous in the sense that it is not possible to enforce this 100%. E.g. if the user kills the browser process then even this JS event would not be published.
Furthermore, a user can simply use another browser to bypass your 'protection'.
In the server side users HTTP session is normally invalided after a certain period of idle time. You can implement http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpSessionListener.html and register it in web.xml to receive notifications about session create/destroy etc. In your listener implementation you could delete the table entry on session destroy event.
The basic thing about HTTP is that it is request/response protocol.
i.e. Things are changed/accessed only by making a request to the server. This 'limitation' makes your requirement interesting. There can be two workarounds for this:-
Poll the server at a repeated interval through an AJAX call. As long as you application keeps getting the polling AJAX request you can assume that the window is open.
Use javascript (window.onunload ) to fire an event to destroy user session when the browser is closed.
Using onuload
Is it possible to manually reset the timeout interval of a specific session for a user that is currently logged in my web app?
I would like the ability to do something similar to this :
public void keepAliveForUser(long userID) {
Session session = this.userSessionManager.getUserSessionById(userID);
session.resetTimeOut();
}
P.S - keep in mind this function is not being called in a follow up to a user request. (i.e. It's called from a cron job, a scheduled task, etc...)
Thanks!
You can use HttpSession#setMaxInactiveInterval to change the session expiry time on the fly
Java Doc
Specifies the time, in seconds, between client requests before the
servlet container will invalidate this session. A negative time
indicates the session should never timeout.
Usage
//session will expire after 2 hours of inactivity
session.setMaxInactiveInterval(2 * 60 * 60);
Session timeout hierarchy:
$tomcat_home/conf/web.xml
$your_webapp/WEB-INF/web.xml
manual invocation of HttpSession.setMaxInactiveInterval(int)
Sorry for the broad topic. Basically, WSC is supposed to have out-of-the-box session timeout handling by forwarding the user to the ReLogonFormView, which the user can presumably configure (through Struts) to any jsp that they choose. We use a custom logoff command, and it seems to be affecting that view showing up.
I'm not looking for a specific solution to this problem, I'm just looking for general knowledge about how WSC (v6) handles session timeouts (how it determines that the session has timed out) and what command(s) it runs by default when / if / to determine the session has expired.
This is my current knowledge on this subject...
The session timeout is a global value for all web modules and can be found in the wc-server.xml and is set to 30 minutes OOTB.
When a timout occurs, the OOTB LogoffCmd would normally be called, which will set up the necessary URLs to navigate to the ReLogonFormView URL while keeping hold of the URL where the session timeout occurred.
If the ReLogonFormView contains userid/password fields to allow the user to logon again, the user will then be redirected back to the page they were originally on.
More info can be found in IBM InfoCenter under "LoginTimeout".
If you extend the OOTB LogonCmdImpl, you should not try and set the forwarding URL, or that will interfere with the OOTB navigation.
I think you should perform your custom logoff functionality and then call super.performExecute() to allow the OOTB navigation logic to take over.
Note: You can retrieve the URL you were originally on via a call to getReferrerURL() and the ReLogonFormView should be returned from getURL().
We have a spring security application with a pretty standard setup. Currently we only allow 1 session per principal, rejecting additional logins by the same principal until the first session is logged out or expired (maximumSessions=1, excpeptionIfMaximumExceeded=true).
I'd like to change this so that when a principal logs in a second time with a currently active login on another session the first session is invalidated/replaced. This is easily accomplished using the provided spring security concurrent session control strategy but I am having trouble figuring out how to alert the user. When a user's session is replaced the session is invalidated by the logout handler. The next request will get a redirect to the login page with a error code on the query string. However, if the request which gets this redirect is an image or other non-programatic call I'm unable to handle this.
It seems like I need to put the user into an inbetween state, where they have a session but it is expired and they need to log back in if they didn't mean to replace their original session. However I don't see a good way to do this.
Is there an example of a setup like this somewhere?
Have you thought of working out a polling mechanism in javascript to alert the user when their session is about to be invalidated? This way they will know that their session isnt valid and possibly have a chance to refresh it in case they have partially filled out forms or text areas.
This can also work from the login side. You can add a step after login if they have another session active and have them verify they want to invalidate it.
It seems that an in between step isnt necessary because, generally,authentication should be boolean. Either they are authenticated or they arent. The inbetween zone might be tougher to handle all cases for.
I have a jsp servlet based application, with session time out of 30 mins, I want to invalidate the session as soon as a person closes the browser window intentionally or accidentally (OS shutdown/close from tast manager/powerdown)
Can I put a check for that and invalidate the session?
It is not possible to handle this scenario .
There are some browsers which provide this setting as their preference , but you can't handle this programitically.
At max:
You can make a poll from page(may be header) same as gtalk in gmail as soon as connection closes wipe that session out.
Why do you want to do that, you have already configured that in server that ,session should stay idle for 30 mins,after that it will expire in server.
if you want to do that use the following javascript or jquery(better for cross browser) , when the browse close event happens send an ajax request to invalidate session by running following code in jsp
(request.getSession(false).setMaxInactiveInteral(0);)
From javascript
<body onbeforeunload="doAjaxCall();">
(or)
jQuery(window).bind("beforeunload", function(){
// Do ajax request and dont wait for the response.
});
You can implement the server push ajax polling , for example think that session is going to expire in another 2 seconds , send a server side request to client to invalidate the cookie and also in the server you can invalidate the session.
if ( (getcurrentTime() - session.getCreationTime()) > 2000 ) {
}
While the page is rendered , get the maxinactiveinterval and then set the value to the JavaScript variable , then use setInterval function , pass the inactiveinterval value to function , once the timeout happens you can set the cookie to expire.
No I don't believe you can do that as there are no hooks available in the browser to get it to send a disconnect notification (of some sort) when it closes and I don't think there is a server-side mechanism to interrogate recent sessions to test their connection status.
If you are using tomcat 5.0/5.5/6.0 container, the cookie generated by tomcat session manager to track the session (JSESSIONID) is a per-session cookie (browser memory only cookie) instead of a persistent cookie (write to disk). That's because the session manager does (hardcoded) setMaxAge(-1), so that the generated HTTP-response contains:
Set-Cookie: JSESSIONID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Path=/ and no Expire=date.
So when the browser is closed (all browser windows, or just the window containing the cookie, depending on the variuos browser implementations), the cookie - and the session - are lost. [*]
This has nothing to do with <session-timeout>, which is a setting that tells the tomcat server-side session manager to expire sessions when idle for more time than specified.
[*] they will still be persisted on disk on the server-side, till session-timeout expires, but there wont be a request with a cookie activating them.