Filter Behavior & null Attribute in Tomcat

Discussion in 'Programming/Scripts' started by anw, May 19, 2007.

  1. anw

    anw New Member

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

    anw New Member

    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
     
  3. anw

    anw New Member

    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
     
  4. falko

    falko Super Moderator ISPConfig Developer

    Unfortunately I'm no Tomcat/.jsp expert... :(
     
  5. anw

    anw New Member

    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! :rolleyes:
     
  6. anw

    anw New Member

    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.
     

Share This Page