tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Williams, Allen" <awill...@harris.com>
Subject RE: Session IDs & XMLHttpRequests
Date Mon, 21 May 2007 19:05:08 GMT
 
> I'd say if there are differences, it's in the javascript of 
> the client.  

Yeah, the problem is that the guts of the client JS are pretty opaque.

> Have you used any sort of monitoring tool to find out if 
> XMLHttpRequest 
> is sending the session cookie?  

No, but I was going to modify the code to print out all the cookies.
That's what I did in the filter to determine that it was holding two
JSESSIONID's.  I'll do that and post again.

> Have you tried encoding the 
> JSESSIONID 
> in the XMLHttpRequest via javascript?

You mean as query parameters in the URL?  What I was
actually going to do is send the database key of the
objects I needed as a query parameter, which I can
send as a POST and not have it show up in the URL,
but that means I have to arrange for Javascript to get
the keys, which means I have to pass them around as query
parameters in the URLs, which I really don't want to do.
Actually, I guess I could store them as cookies.  I really
like only having that information on the server, though.

I was also going to print out as much of the HTTP request as I could
find APIs
for and see what that looked like.

Thanks!  Any further ideas will be looked upon with unlimited favor;-)
> 
> --David
> 
> Williams, Allen wrote:
> 
> >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
> >
> >  
> >
> 
> 
> ---------------------------------------------------------------------
> 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
> 
> 

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