Session depends on Browser?

General
1

Greetings!

I’m new to Vaadin and trying to figure out how the Session Management works. While playing around with the AddressBook example application I noted that if I reload the page in browser my session is handled differently depending on am I running it from inside the Eclips or it is deployed to the Tomcat (as war file). Moreover, I noted it works differently depending on the browser I used.

What I did: after running AddressBook I added a new contact, change sort order, and things like that. Then I reload the page in browser, got the following:

  • If application has been started from the Eclipse (though in external browser) then the session is kept, all my changes in the application are preserved, I continue from the same point where I reloaded the page;
  • If application is deployed to the Tomcat and is running directly - then it depends on browser used. The session is preserved in Firefox, but on other browsers - Chrome, Safari, IE9, Opera - application is completely restarted, loosing all the changes.

According to Book of Vaadin the session should be preserved even if page is reloaded, unless ?restartApplication parameter is added, but it’s not.

Could somebody please explain me why this is happening? Is there a way to handle this? I mean to preserve the session not depending on the browser used?

I’m sorry if this already been asked, but I couldn’t find similar thread.

Thank you!

2

The session should always be preserved when reloading the page in the browser. In your case, I’d guess the problem is related to the cookies used to keep track of the session.

You could compare the HTTP cookie headers in responsens and requests between Firefox (using the Net panel in Firebug) and in e.g. Chrome (using the Network section in the Inspector) to find clues to what’s causing the difference between the browsers and between the deployment approaches.

3

Hi Leif and thanks a lot for your advise.

I tried to watch the cookies as you recommended. So here is what I’ve got form after browser refresh.

Firefox:

Response Headers
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 2604
Date: Mon, 12 Mar 2012 16:36:16 GMT

Request Headers
GET /AddressBook HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: JSESSIONID=110959AF86DFC4A4DB839DCE5329509F
Cache-Control: max-age=0

Response Headers
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html
Transfer-Encoding: chunked
Date: Mon, 12 Mar 2012 16:36:16 GMT

Request Headers
GET /AddressBook/VAADIN/widgetsets/com.vaadin.terminal.gwt.DefaultWidgetSet/516172B066DA8C0C150C685E3318393D.cache.html HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost:8080/AddressBook
Cookie: JSESSIONID=110959AF86DFC4A4DB839DCE5329509F

Chrome:

Request Headers
GET /AddressBook/VAADIN/themes/runo/table/img/resizer-bg.png HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.78 Safari/535.11
Accept: */*
Referer: http://localhost:8080/AddressBook
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=2CD3536D410CCC7AA8B11EAF97C3D3EE

Response Headers
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: image/png
Content-Length: 141
Date: Mon, 12 Mar 2012 17:01:38 GMT

Request Headers
GET /AddressBook/VAADIN/themes/runo/table/img/resizer-bg.png HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.78 Safari/535.11
Accept: */*
Referer: http://localhost:8080/AddressBook
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=50BADEB964E165E98C0B128E2162FED7

Response Headers
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: image/png
Content-Length: 141
Date: Mon, 12 Mar 2012 17:02:40 GMT

Well, I can’t see a fundamental difference between the headers in Chrome and Firefox, except that Firefox continue using the same session (JSESSIONID=110959AF86DFC4A4DB839DCE5329509F) after page refresh, while Chrome gets a new session (JSESSIONID=50BADEB964E165E98C0B128E2162FED7 vs JSESSIONID=2CD3536D410CCC7AA8B11EAF97C3D3EE).

Tomcat’s Session Administration page just confirms this: new session has been thrown for application on Chrome and the same session remains for Firefox.

Any comments are very welcome…

4

Browsers doesn’t suddenly start sending different cookies without being asked to do so by the server (or by javascript, but that is probably not the case here). I suspect there is a response from the server in between those requests with the new JSESSIONID cookie value in its response header. I further suspect that the server sends a new cookie value because it is missing from some reqeuest, which might be caused by the cookie only being set for a specific path (typically just an offending ending slash).

Sometimes just clearing the cookies in the browser might help. In other cases you have to instruct the servlet container to use a more generic path for its session cookies, e.g. using sessionCookiePath or sessionCookiePathUsesTrailingSlash in Tomcat’s
context configuration
.

5

Your suspicion confirmed! It was the problem of the ending slash. The issue was solved by setting the sessionCookiePathUsesTrailingSlash parameter to false. I created the
context.xml
 file under META-INF directory within the project, having the following statement:

<?xml version='1.0' encoding='utf-8'?>

<Context sessionCookiePathUsesTrailingSlash='false'> 
</Context>

After that the session is kept after page reload. I’ve just tested it with all major browsers I have installed.

Thank you so much for your help!

6

This bothered me for a long time, this should be Tomcat specific problems, glassfish automatically add /
Jurijs buts recommendations can solve this problem
tomcat Location
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

7

This bothered me for a long time, too.

My Vaadin app was finished and working well. Then, I put a login.jsp in front of it with a Spring Security filter. There seemed to be no problem at first because (a.) my browser (Iron) had memorized the address with the trailing slash and I never checked without the slash, and (b.) I think Eclipse was somehow adding the trailing slash on launch in the IDE’s Tomcat. So I deployed the new version to our server. We use Tomcat.

But then the QA team tried it and got a redirect loop back to the login.jsp.

In IE, Chrome, or Iron, my users get redirected back to my login.jsp in a redirect loop if they try to enter my Vaadin app by typing the URL into the address bar without a trailing slash. The problem did not occur in Firefox or whenever the user added a trailing slash.

I added the sessionCookiePathUsesTrailingSlash=‘false’ setting and this fixed the issue.

There is a caution
here
 that your JSESSIONID cookie might not be cleaned up at the end of a session if you use this fix, so you must add a patch for that. Further info
here
 and
here
.