tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Williams, Allen" <awill...@harris.com>
Subject Session IDs & XMLHttpRequests
Date Mon, 21 May 2007 18:33:15 GMT
I had posted this question to four different Java fora over four days
and gotten zero replies, when it occurred to me how stupid not to ask
the community that wrote Tomcat.  I was just going to post this, which
is a summary that describes what I've found so far:
 
-- QUOTE --
In the interest of informing the community, I'm publishing the results
of four days of testing and debugging of XMLHttpRequests and attributes.
This has led me to the conclusion that servlets invoked with an
XMLHttpRequest do not have the same access to server-side objects
(actually, attributes) as those invoked via the normal URL mechanism. I
don't know why, because if I insert a filter, the filter gets executed,
albeit the first time with the wrong session ID.

I began this odyssey when a filter in place to check if a user's session
had timed out would fail the first time when invoked with an
XMLHttpRequest, but would work each time thereafter. What I discovered
there was that there were two JSESSIONID cookies stored and being sent
in the browser and the jsp and other servlets were requesting the
correct one. The xml request was not, it was requesting the (old? I
don't know) invalid JSESSIONID. One would think, "OK, I'll just read the
cookies in my servlet, check each ID with
request.isRequestedSessionIdValid(), and force the right one". Wrong.
All of the http session APIs that allow one to manipulate the session ID
and force a good one are deprecated, according to Sun's web site, so the
programmer isn't allowed to find & use a good session ID.

In order to progress while I waited vainly for a reply, I just removed
the filter from the servlet's path so it didn't invoke it. I want the
filter to check, but decided to move on in the meantime. That's when I
discovered that, evidently, the servlet does not get a valid session ID
either.

I had the following line in my XMLHttpRequest servlet:

[code]
HttpSession sess= req.getSession();
[/code]

This seemed to execute and work fine, until I needed to access
session-scoped attributes I had defined in other pages or servlets. The
were repeatedly null. When I changed the above line to this:

[code]
HttpSession sess= req.getSession(false);
[/code]

the reason was apparent: the servlet was generating a brand new session
for me. So, for some reason, XMLHttpRequests don't get the same
treatment that normal servlets get. I'm going to have to go and modify a
lot of code to pass stuff around as query parameters in URLs, which I
really don't want to do for both aesthetic & security reasons, but see
no alternative. Hopefully, there really is someone out there that knows
more about this than I do and can explain to the community & me what's
going on.
-- END QUOTE --

1. So the last paragraph has my main question in it: why can't I access
attributes in a servlet invoked via an XMLHttpRequest?  However, I have
a another important question and a couple of ancillary ones as well:

2. What is the difference in the servlet invocation between a regular
URL invocation & an XMLHttpInvocation?

3. How can I get my filter to work?  I. e., get it the correct session
ID?

4.  WHY are all the session manipulation APIs deprecated, and, at least
according to Sun's web site, not being replaced?  It seems unusual to be
removing control from the programmer/software engineer instead of trying
to give him more control over his environment.  With those APIs I could
have fixed this (well, kludged it up, anyway).

If you need me to post any code, I'll be glad to, but it's really pretty
straightforward.  In fact, when I started this adventure, the servlet
was empty except for print statements, and the filter has been in place
& working for months.

Thanks!!

anw


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message