Bean is null in an XMLHttpRequest (at first)

[Allen Williams]

I have a client/server AJAX-type script, and an Java session-scoped attribute on the server called "user". In order to detect a timout 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).

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

TIA,
ANW

[Bear Bibeault]

Hmmm, this is not something I've ever come across and I do the exact same sort of thing routinely.

Things I'd try as diagnostic steps were it happening to me:

1) try it from different browsers to see if it's the browser screwing with the session cookie
2) investigate if the session itself in the errant request is the same or different than expected
3) check the timing of the requests... is a race condition somehow being created?
...

[Allen Williams]

Ha! As usual, you seem to have hit upon something. #3 (I think) was my comment about initialization, but now I've investigated 1 & 2. Here is the print statement in the filter (as it is when now that I added session checking):

        Log.write("\nCheckUser: :mrgreen: oFilter: next url, session= '" + chkurl.toString() + "' '" + req.getSession() + "'");

So, I'm now printing out the session. When I first click into the area where the problem url is, I get this:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

Then, when I first click the problem url, I get this:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/members/servlet/ForumMgr' 'org.apache.catalina.session.StandardSessionFacade@1cf662f'
May 18 20:45:58: CheckUser: oFilter: Invalid!! validAccess returned 2

The Invalid message is because the user bean is null. Then, every time after that, I get:

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/infoisland/members/trbfrm.jsp/tkey=6' 'org.apache.catalina.session.StandardSessionFacade@1cee792'

CheckUser: oFilter: next url, session= 'https://anw-dev/members/servlet/ForumMgr' 'org.apache.catalina.session.StandardSessionFacade@1cf662f'

Note, of course, that the filter seems to be getting called three times, twice with the same session, once with the "new" session, but now the new session doesn't have a null user bean.

Any further ideas?

[Allen Williams]

As an afterthought, wouldn't there only be one "session per session", so to speak?

And, sorry about the smileys- don't know how they got in there. That's just a reference to the function: CheckUser:"do"Filter.

[Allen Williams]

I'm continuing to experiment, and maybe I'm only getting two CheckUser's after this initial one where the bean is null (I get three there- two with the original session, then one with a "new" session & a null bean). Don't know if I made a mistake the first time, but the three CheckUser's is only on the first time where the last one is a new session with a null bean.
After that, I get two sessions, the original and the "new" one, but no more null beans. And it's always the same two sessions.

[Allen Williams]

Oops! One more comment- consistent with my first post after your reply, I did check the browser. This does not happen in IE, so maybe it's some sort of cookie thing? But, still, why am I getting two sessions?

[Allen Williams]

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

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???

TIA
anw

[Allen Williams]

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:

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

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

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:

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

and the result:

May 19 19:31:12: requested session is '5FEC48F83C200794A369105D62A23AA6'
May 19 19:31:12: valid session? false
May 19 19:31:12: CheckUser: :mrgreen: oFilter: 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:

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:

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

[Allen Williams]

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.