Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
SessionGuard
To continue with the invisible widgets series, it's time for the SessionGuard.
The idea of this component is to handle the Vaadin sessions. The main function of this component is to announce to the application user, that her session is about to end, to give her a chance to react before the session invalidates. This component also makes sure that, when the session has ended, the Vaadin message will be presented proactively, and not when the user tries to do something.
The SessionGuard may also be used to keep the session artificially alive. Since this implementation is on the client side, the session never dies while the browser is open, but may die once the browser session is ended by the user. This allows for short session times in your web.xml, if you want that kind of thing.
The sources, along with a Vaadin add-on jar, may be found at http://github.com/wolfie/SessionGuard. An example on its usage is also available. That example runs at http://henrik.virtuallypreinstalled.com/SessionGuard, which you are welcome to give a go.
As usual, licensed under Apache 2.0
Thanks for this Henrik - this solves a problem I'm bound to have in a couple of month's time after I've got the rest of my UI sorted =)
It's great to hear, guys! please do tell me your experiences/problems if you start using this.
Although the current version is 0.0.3, I think I have to promote it to 1.0.0 stable pretty soon, since I don't have many ideas of improvement. I might implement a maximum keepalive-time, but we'll see about that.
One idea which comes to me - when a "session about expire" message appears, probably, its another variant would be useful - a notification or a dialog with some text and and 2 buttons - "close" and "continue", so this will act like this:
"Your session is about expire, click "continue" to stay on site or "close" to exit".
[code]
So, "continue" button will reset the inactivity times and close the notification and the "close" button will also terminate the application.
I actually thought about that a bit.
The reason I chose this method (and probably will stick with) is the probability of "being there to care". Let's assume that the session length is 60 minutes, and the warning period is 10 minutes; the probability of the person being away for 50 minutes, and coming back during the last 10 minutes' time frame are somewhat slim, as the odds decrease as time passes. Even if the person gets back within that window, if he cares enough, he'll probably just continue working and close the notification. Otherwise he'll just ignore the window, and the session is allowed to time out. As you probably know, this is what the component does now.
I don't believe someone would care enough to open the window, close the warning by choosing "continue", just to let the session expire. If the the user needed some information right from behind the notification or something, the notification still can be closed. Okay, so the session timer gets reset, but that's no biggie since it'll run out again in an hour-or-so.
I've not used it yet, so perhaps it works this way already, but some sites will have short session timeouts, say 10-15 minutes, so that users are either active and working or they are terminated. This is often the case for systems containing sensitive info where 60 minutes is way to long to allow an app to be exposed while someone is away.
When the session is about to expire, if the user could continue/quit, it might be nice to have a "logout event" sent to the server so that it could do whatever processing normally occurs on logout, which often includes changing the page so that the data visible is cleared and a login page is displayed. Again, this helps keep the page secure when the session ends, since now the data stays on the screen and it's only when someone tries to click does the session expired message appear and they are directed to the logout page.
When session ends (by a timeout or by explicit end by a app event - button "close" or signal from session guard) Vaadin application terminates and it's close() method called, so any resources could be freed there. Also, when application closes, browser is forced to navigate to a "logout url", so sensitive screen data will be removed in such case, I think
Good points. Created a ticket for including this functionality directly to Vaadin. Please comment at http://dev.vaadin.com/ticket/4155.
I wonder. Could this component be modified to act as a sort of screen saver? I'd like to give my application a short timeout and hold the session open using SessionGuard. But it'd be neat if after, say, 10 mins of inactivity I could prompt the user for their password while holding the session open.
I guess this change is a little deeper, though. I'd need to deal with the case where the user just hits refresh and I don't know how I'd do that just yet.
Fredrik has already done a screensaver add-on, which I imagine should work well with the SessionGuard (can't see why not, but haven't tested). I don't think his screensaver has a password functionality just yet, but I guess it might make a nice feature for it!
Check out the forum thread at http://vaadin.com/forum/-/message_boards/message/104125
Royce Ausburn: I wonder. Could this component be modified to act as a sort of screen saver? I'd like to give my application a short timeout and hold the session open using SessionGuard. But it'd be neat if after, say, 10 mins of inactivity I could prompt the user for their password while holding the session open.
Good idea. Added to http://dev.vaadin.com/ticket/4155.
hi,
I used netbeans to run SessionGuard with this tree below.
but a had this error :
This application has a 3-minute session, with a timeout warning of 2 minutes session time left.
Widgetset does not contain implementation for com.github.wolfie.sessionguard.SessionGuard. Check its @ClientWidget mapping, widgetsets GWT module descrioption file and re-compile your widgetset. Unrendered UIDL:
com.github.wolfie.sessionguard.SessionGuard(NO CLIENT IMPLEMENTATION FOUND)
you have an idea about it and how do I fix it.
thank you
it seems you haven't recompiled your widgetset. Since you are using NetBeans, I'm not much of help there since I work only in Eclipse, and the Vaadin plugin for Eclipse does all that for me. I'm not sure whether the NetBeans plugin does that. But, as far as I know, the Vaadin release has an Ant build script (should be at WebContent/docs/example-source/build-widgetset.xml) that can rebuild your widgetset.
Hopefully that will of some help
Can't access to source plug-in: http://github.com/wolfie/SessionGuard
Ramzi Youssef: Can't access to source plug-in: http://github.com/wolfie/SessionGuard
You need to elaborate a bit more than that.
That's a website to look at the source code. The JAR file is in the root of the project, which you can download by first clicking the file name, and then clicking the "view raw"-link. The Jar file can compiled into your widgetset the easiest if you use Eclipse and Vaadin's Eclipse plugin by adding the JAR into your WebContent/WEB-INF/lib/ -directory.
The project itself is a Git project that you can clone from the address git://github.com/wolfie/SessionGuard.git
Thanks a lot. I installed the GIT plug-in on eclipse. I have the source code now. I'll try now to implement the SessionGuard in my project. By the way what are the future plans for SessionGuard plug-in ?
Ramzi Youssef: By the way what are the future plans for SessionGuard plug-in ?
I think once I get around implementing a maximum keepalive period in a sensible way, I think I'll call it 1.0.0, stable and done. There's not much you can do with the session without going out of bounds of the component's responsibilities. Besides, as mentioned earlier, these features are being planned to be an integral part of Vaadin. There's not much use to plan a an extensive future, apart from the occasional bug fix, for this component.
Hi,
I'm very interested in SessionGuard benefits. So I got the code from these locations.
Henrik Paul: The sources, along with a Vaadin add-on jar, may be found at http://github.com/wolfie/SessionGuard. An example on its usage is also available. That example runs at http://henrik.virtuallypreinstalled.com/SessionGuard, which you are welcome to give a go.
I implemented SessionGuard as described in the example (within init()):
SessionGuard sessionGuard = new SessionGuard();
sessionGuard.setKeepalive(true);
mainWindow.addComponent(sessionGuard);
But when I startet the application I got these error messages:
javax.servlet.ServletException: java.lang.UnsupportedClassVersionError: (com/github/wolfie/sessionguard/SessionGuard) bad major version at offset=6 (unable to load class com.github.wolfie.sessionguard.SessionGuard)
...
and
java.lang.UnsupportedClassVersionError: (com/github/wolfie/sessionguard/SessionGuard) bad major version at offset=6 (unable to load class com.github.wolfie.sessionguard.SessionGuard)
...
Any ideas what went wrong?
Thanks, Thorsten
••••••••••
Eclipse 3.5.1 • Vaadin 6.2.2 • Vaadin Eclipse Integration 1.2.0
Windows 2000 • IE7 • Tomcat 6.0
Thorsten A: ...when I startet the application I got these error messages:
javax.servlet.ServletException: java.lang.UnsupportedClassVersionError: (com/github/wolfie/sessionguard/SessionGuard) bad major version at offset=6 (unable to load class com.github.wolfie.sessionguard.SessionGuard) ...
I'm not completely sure what that indicates. If you're using the provided JAR, it sounds like my SessionGuard is compiled with an incompatible version of Java, a version that doesn't work with what you're using now. It should be compiled for Java 1.5, but, admittedly, I might've been sloppy and mistakenly compiled it with Java 6.
Make sure that you're using at least Sun's (the vendor shouldn't matter) JDK 1.5. If that doesn't work, try changing to Java 6, and see if that works better.
But, if you have downloaded the whole source, and compiled the widgetset yourself. Well, then I'm out of ideas, I'm afraid.
Hi Henrik,
Henrik Paul: If you're using the provided JAR, it sounds like my SessionGuard is compiled with an incompatible version of Java, a version that doesn't work with what you're using now. It should be compiled for Java 1.5, but, admittedly, I might've been sloppy and mistakenly compiled it with Java 6.
good hint!
Finally I copied your source code directly in my project. This compiles and works fine with my default Java 1.5!
Thanks, Thorsten
••••••••••
Eclipse 3.5.1 • Vaadin 6.2.2 • Vaadin Eclipse Integration 1.2.0 • Java 1.5
Windows 2000 • IE7 • Tomcat 6.0
HI Henrik,
Just downloaded your 0.0.3 version of SessionGuard.
Line 157 in SessionGuard#setTimeoutWarningHTML. I think it should read
if(timeoutWarningHTML != null) {
...
...
}
I'm getting a NPE when I set the value :-/
-=bootlaces=-
Boot Laces: Line 157 in SessionGuard#setTimeoutWarningHTML.
I'm getting a NPE when I set the value :-/
Well, isn't that an embarrassing bug. Good that I haven't promoted that to Stable from Beta ;) Thanks for trying, noticing and reporting. As a prize, here's a fixed version 0.0.4: http://vaadin.com/directory#addon/71!
I try to use Session Guard with portlet V2.0, ApplicationPortlet2 and PortletApplicationContext2 and I got an exception:
Caused by: java.lang.ClassCastException: class com.github.wolfie.sessionguard.SessionGuard must be used in a com.vaadin.terminal.gwt.server.
WebApplicationContext, currently trying to be used in a com.vaadin.terminal.gwt.server.PortletApplicationContext2.
at com.github.wolfie.sessionguard.SessionGuard.attach(SessionGuard.java:72)
at com.vaadin.ui.AbstractComponent.setParent(AbstractComponent.java:569)
at com.vaadin.ui.AbstractComponentContainer.addComponent(AbstractComponentContainer.java:207)
at com.vaadin.ui.AbstractOrderedLayout.addComponent(AbstractOrderedLayout.java:68)
at com.spribo.vaadin.ui.SpriboVerticalLayout.addComponent(SpriboVerticalLayout.java:50001)
at com.spribo.vaadin.portlet.target.zone.ui.TargetView.addComponent(TargetView.java:50001)
at com.vaadin.ui.Panel.addComponent(Panel.java:280)
at com.vaadin.ui.Window.addComponent(Window.java:215)
at com.qoslabs.phronesis.hermeneutics.PortletApplication.init(PortletApplication.java:294)
at com.spribo.vaadin.portlet.SpriboApplication.init(SpriboApplication.java:50001)
at com.spribo.vaadin.portlet.target.zone.TargetZonePortlet.init(TargetZonePortlet.java:50001)
at com.vaadin.Application.start(Application.java:545)
at com.qoslabs.phronesis.hermeneutics.PortletApplication.start(PortletApplication.java:50001)
at com.spribo.vaadin.portlet.SpriboApplication.start(SpriboApplication.java:50001)
at com.spribo.vaadin.portlet.target.zone.TargetZonePortlet.start(TargetZonePortlet.java:50001)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.startApplication(AbstractApplicationPortlet.java:750)
at com.vaadin.terminal.gwt.server.AbstractApplicationPortlet.handleRequest(AbstractApplicationPortlet.java:399)
... 137 more
Checking code I see next lines:
final ApplicationContext context = application.getContext();
if (context instanceof WebApplicationContext) {
final WebApplicationContext webContext = (WebApplicationContext) context;
sessionTimeout = webContext.getHttpSession().getMaxInactiveInterval();
} else {
throw new ClassCastException(getClass() + " must be used in a "
+ WebApplicationContext.class.getName()
+ ", currently trying to be used in a "
+ context.getClass().getName() + ".");
}
Are there any special reason to don't support PortletApplicationContext2?
Federico Hernandez: Are there any special reason to don't support PortletApplicationContext2?
Hm, I've made this decision a good time ago, so I've forgotten the particulars. But, IIRC, the functionality depends it on being a true application context, so that the component can reliably get a correct session length.
I've never used portlets myself, so I haven't really tested whether my assumptions are true or not, but I can imagine it might wreak havoc if wrong session info is retrieved.
Be how it may, I wanted to make sure that the component isn't used in murky waters, that might cause weird behavior. If you feel adventurous, feel free to get the source code, remove that check, recompile the widget and see what happens. I'd be interested to hear the results.
Hi Henrik
I changed Session Guard code to use PortletApplicationContext2 and I add it to one of my portlets, I saw the warning message, but after session time out I saw a
Communication problem
message instead of
Session expired
message.
I'm using Vaadin 6.3.4 with Liferay 5.2.3, and I'm not sure who is displaying the
Session expired
message that I saw in your on live demo. Any ideas?
Thanks
Hi Henrik
I was looking for different messages at Vaadin and I found where messages are generated:
- For portlet 2.0 AbstractApplicationPortlet generates the message and it set "Communication problem"
- For servlet AbstractApplicationServlet generates the message and it set "Session expired"
Servlet manage in a better way SessionExpiredException than portlet, so I think my issue was at Vaadin code.
Thanks
Hi,
I would also be interested in this feature in portlet context.
Have you succeeded in integrate this feature in this context ?
If it is ok, i can try it. It could be interesting to make this component compliant.
If you want, i also can contribute for it.
Regards,
Pierre
Pierre Le Roux: I would also be interested in this feature in portlet context.
Have you succeeded in integrate this feature in this context ?
Sorry, I have no experiences in using portlets, so I have no guarantees that whether this works in portlets or not.
Pierre Le Roux: If it is ok, i can try it. It could be interesting to make this component compliant.
If you want, i also can contribute for it.
You're free to try. The addon is released under the Apache 2.0 license, so you're free to modify it. Since the sources are up on GitHub, feel free to fork the project and give me a pull request. I have no idea whether I get messaged from the request, so it's best that you reply to this thread afterwards, just to make sure.
Thank you for this Add-on Henrik!
We (no me personally) have put it on BlackBeltFactory.com, in production.
But it seems not to work (I still see the red box "Session Expired").
We probably do something wrong.
SessionGuard sessionGuard = new SessionGuard();
sessionGuard.setKeepalive(true); // true = keeps the session alive
window.addComponent(sessionGuard);
I don't think that we have recompiled the widgetset. Do we need to do that?
Many thanks.
John.
John Rizzo: We (no me personally) have put it on BlackBeltFactory.com, in production.
Holy moly that's awesome to hear!
John Rizzo: But it seems not to work (I still see the red box "Session Expired").
...uh-oh.
John Rizzo: I don't think that we have recompiled the widgetset. Do we need to do that?
The code above looked very ok. But since the widget does have a client-side part (unfortunately :/ ), the widgetset needs to be recompiled. Try that, and if it still doesn't work, please report back with the version of Vaadin you're using, and I probably need to know which server you're using.
Hope it's just a matter of a recompilation of the widgetset.
Hi Henrik,
We redeployed a version with the recompiled wigetset and it does not work for us. We still have the red "Session Expired" box after 30 minutes of inactivity.
We use Tomcat 6, and Vaadin 6.5.4.
You can check at BlackBeltFactory.com
Any idea how to debug this?
Many thanks.
John.
John Rizzo: Any idea how to debug this?
I have no direct hunch as to why it shouldn't work. I developed this with Tomcat 6 (changing this, I feel, should be the only reason why it would break) but with an earlier version of Vaadin.
Just a sanity check: Is the component 'visible' at all times? Since this is a client-side component, you need to have the component present in all views you have. So, it doesn't suffice to have it added to a layout once, and then be done with it.
I'll look into this tomorrow (Friday) and I'll report back as soon as I get something out of this. Sorry for your troubles :(
Running on the Tomcat and Vaadin versions you named, my test application doesn't fail :/
One thing you could check is to make sure that the following code (try it from your Application's init()-method) results to the equal to the timeout in minutes you have configured for Tomcat:
((WebApplicationContext) getContext()).getHttpSession().getMaxInactiveInterval() / 60
If it does, I'm stumped. If it doesn't, however, that's a possible problem. If you have not defined the servlet's timeout in the web.xml, you should try to do that, by adding the following lines underneath the closing tag </contextParam>:
<session-config>
<session-timeout>5</session-timeout>
</session-config>
Henrik Paul: Just a sanity check: Is the component 'visible' at all times?
How do you check that?
Henrik Paul: One thing you could check is to make sure that the following code (try it from your Application's init()-method) results to the equal to the timeout in minutes you have configured for Tomcat
Yes, it does.
John Rizzo:
Henrik Paul: Just a sanity check: Is the component 'visible' at all times?
How do you check that?
Well, the most reliable way is to go to the view where the session guarding fails, and check the DOM structure in the browser for an element having a sessionguard class name. FireBug works perfectly for this, but Chrome has something similar built-in.
But basically what you want to do is that you make sure that the layout you add the SessionGuard into is never removed from the component tree. The way I do it is to add the SessionGuard directly to the main window, and make sure that view changes don't change the main window's layout, but another layout that's a sibling to the SessionGuard.
If you've ever used a globally functioning UriFragmentUtility, the idea is exactly the same.
The sessionguard was not there.
In the Application, I did add SessionGuard to the main Window.
But later, Navigator7 called Window.setContent() which removed the layout containing the session guard.
The right place for me is to instantiate the SessionGuard in my descendant of NavigableApplicationWindow.createComponent() method.
Now sessionguard is there, and it seems to work.
Thank you Henrik!
John Rizzo: Now sessionguard is there, and it seems to work.
Thank you Henrik!
No problem John! I'm just glad that you got the thing sorted out.
Would be great if the add-on allowed custom handling of the timeout. For me, displaying just the notification is not enough. I would like to be able to set a listener to the SessionGuard component which would notify me when the time runs out and I could perform any arbitrary action.
But anyway it's a great add-on, keep up the good work!