SessionGuard

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 =)

Yet another great addon widget !
Thanks, Paul !

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.

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 ?

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.

OK Henrik,

I'll have a look.

I tell you more soon.

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!