Session Expired URL Infinite Loop

General
1

Hello.

We are required to implement the “on session expiration go back to the login page” behavior. However our client didn’t like the default system message and we had to find a way to be rid of it.

I found the section on system messages so I implemented it like this:

messages.setSessionExpiredCaption(null);
messages.setSessionExpiredMessage(null);
messages.setSessionExpiredNotificationEnabled(false);
messages.setSessionExpiredURL(ConfigurationService.SESSION_EXPIRED_URL);

being SESSION_EXPIRED_URL the base url for the project plus “?restartApplication” and it seems to work well in the development environment but sometimes we have some odd behavior:

When the login page loads we set focus on the first field, when that field loses focus it reloads the whole page again and again until we close the browser and load it again.

We’ve seen this happen with the application running on tomcat 6, weblogic 12 and internet explorer 8, 9, the latest chrome, firefox 14, and safari 5.

We’re using vaadin 6.8.4.

It seems to happen most when we’ve just redeployed the application.

What am I doing wrong?

We get this warning on the chrome console when this happens:

Resource interpreted as Script but transferred with MIME type text/plain: “http://172.16.25.31:7001/Stcv6/VAADIN/widgetsets/com.bytesw.tel.stc6.widget…etset/com.bytesw.tel.stc6.widgetset.Stc6Widgetset.nocache.js?1362061722785”.

2

After a lot of debugging I came across something.

We’re experiencing that problem only in our QC environment.

Since we need to test the application for deployment to several clients we are currently deploying to glassfish, tomcat and weblogic.

Our problem seems to be cookie related. Since we are deploying to 3 web servers with the same hostname and the war has the same name, it creates a conflict at the cookie level.

And it keeps saying that the session is expired even though vaadin says it’s a new session every time.

3

How are you doing that? Using three distinct port numbers to differentiate them (three of the same webapp name on the same domain name)?

Seems like this not a bug but a deployment issue. Why don’t you deploy them under three different domain names (all can have the same IP address) or three different webapp names (assuming your cookie is set based on the web app name in the path)? Cookies work on domain name and path so if they are not distinct, there’s no way to distinguish! Or you can use three different web browsers when testing them since each will have its own cookie.

4

Strange scenario I know, but it happened because our testers only had the one server and were accesing all three applications from the same browser tab.

Not very likely to be a problem at a production level but it was a very difficult to find the cause.

We just renamed the applications on the tomcat and weblogic and the problem went away.