Filter Behavior & null Attribute in Tomcat

I have a client/server AJAX-type script, and an Java session-scoped
attribute on the server called "user". In order to detect a timeout and
send the user back to the login screen, there is a filter called
"CheckUser" which has been working fine for months, checking for either
the session or the user bean being null.

Now, I'm sending an XMLHttpRequest to a servlet (which isn't the first
of these, although this is a new servlet). The first request
that's sent gets a null user bean (accessed in the filter via a
HttpSession.getAttribute() in the "CheckUser" filter), which causes the
filter to redirect, and the XMLHttpRequest.response contains the HTML
text of the login page. After the first access, the user bean is fine,
and the only time I've seen this is in this XMLHttpRequest (and the request
is built and sent in a library function that's been working fine in other contexts).

This is the problem- this is what I get the first time the request goes out in Firefox:

Note that there are apparently three calls to the filter (I clicked the URL once, the page loaded, then called the servlet, so I would expect two, not three), and the last one is some brand
new session. The "Invalid!!" message is because the user bean is null, but, of course, it
is not null in the first two calls with the original session. And this is what I get each subsequent
time:

Now, it finds the user bean just fine. I did nothing more that click
the URL a second time, and got my expected two filter checks.
Any idea what's happening here? The request is sent in the onload
function for the page, which is the soonest I've ever tried to send a
request (all other times have been in response to a user-triggered
event). Could there be an initialization issue (I'm skeptical here,
because the user bean is set at login, and, by the definition of a
session-scoped variable, should be there until logout or timeout; they
don't come & go between pages, do they)? If you need me to post any
code, I'll be glad to, but I'm not sure what's needed. In fact, I
wasn't sure whether to post here or in the Javascript forum, but what
with it being the failure of the filter & the bean, this is more of a
server-side issue (I think).

 

Since I posted this, I've done a lot more testing. It does exactly the same thing in IE. I changed the filter to

Code:

HttpSession sess= req.getSession(false);

so that it wouldn't create a new session if one didn't exist, and, sure 'nuff, the session comes back null, but only the first time. After that, it gets the session, no problem. Perhaps the page & JS is loading and executing before the cookie representing the session is sent back to the server???

Does anyone out there care to venture an opinion?

TIA
anw

 

OK, more testing. I have printed out the JSESSIONID cookies, and there are multiple (two) of these cookies. I'm not sure what the lifecycles of these JSESSIONIDs are, but they seem to change, and the browser (well, the page) seems to be keeping a couple of them around. The XMLHttpRequest seems to have only one.

When I first go to the page, it has two session id's, which, as we shall see, are a good one and a bad (old?) one. The page sends the good one in for validation, no problem. The XMLHttpRequest sends in only one, and it's the bad one the first time. So, when it first lands on the page, it sends these cookies:

Code:

May 19 19:31:06: 'JSESSIONID'='25A020B648BC88F18B7A95DFA8AD657A'
May 19 19:31:06: 'JSESSIONID'='5FEC48F83C200794A369105D62A23AA6'

and the page, a jsp, requests the following session:

Code:

May 19 19:48:55: requested session is '25A020B648BC88F18B7A95DFA8AD657A'
May 19 19:48:55: valid session? true

Then, along comes the xmlhttp request, and here is the cookie:

Code:

May 19 19:31:12: 'JSESSIONID'='5FEC48F83C200794A369105D62A23AA6'

and the result:

Code:

May 19 19:31:12: requested session is '5FEC48F83C200794A369105D62A23AA6'
May 19 19:31:12: valid session? false
May 19 19:31:12: CheckUser::doFilter: Invalid!! session, validAccess returned null -1

The second time around, it is different. Remember, this is still the XmlHttpRequest, not the page. It hasn't been reloaded since the first pass, above. Cookie-wise:

Code:

May 19 19:48:55: 'JSESSIONID'='9B47C6A64057D3C45FF0C0FA9DBF12B8'

Note that we now have a brand new JSESSION cookie (!?!) which is the one requested by the XMLHttpRequest:

Code:

May 19 19:49:02: requested session is '9B47C6A64057D3C45FF0C0FA9DBF12B8'
May 19 19:49:02: valid session? true

So, how do I get the right JSESSION cookie in the XMLHttpRequest? Or, get the filter to somehow find out the right one? Why would the request be sending the wrong session id?

Does anyone out there now care to venture an opinion?

TIA

 

Unfortunately I'm no Tomcat/.jsp expert...

 

Hey, Falko! Thanks at least for the reply. I've posted this on, now, four forums, and have gotten a response from zero. I suppose the consolation there is that I must be a pretty damned accomplished programmer to have problems no one can solve!

 

OK, I have FOUND the problem, and for the continued edification of the
community will share my results.

It had to do with the context path. Part of the session ID cookie
is a reference to the path that is used. When I went back and associated this
servlet with a valid "used" path but still without the "CheckUser"
involved, updating through my mod_jk.conf, my web.xml for the mappings,
and, of course, the script itself, it picked up the right session id and
the world is good.