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 Tue, 22 May 2007 13:47:30 GMT
Will it work with POST as well as GET?  Although I guess I'll soon find
out;-)

Thanks, and Regards,
________________________
Allen Williams
allen.williams@harris.com
Office: (321)309-7931
Mobile: (321)258-1272
FAX: (321)727-9607
 

> -----Original Message-----
> From: David Smith [mailto:dns4@cornell.edu] 
> Sent: Tuesday, May 22, 2007 9:17 AM
> To: Tomcat Users List
> Subject: Re: Session IDs & XMLHttpRequests
> 
> As long as it's encoded on the url as shown in the example below (and 
> defined in the servlet spec), tomcat will just pick it  up 
> and use it.  
> No additional APIs required.
> 
> --David
> 
> Williams, Allen wrote:
> 
> >Thanks for the hint.  I had come to the conclusion I was 
> going to have
> >to do something like that.  It is not a JS framework- it's 
> Javascript &
> >Java in a Tomcat container, all built in-house.
> >
> >Again, I looked at the XMLHttpRequest with Firebug, but saw 
> no reference
> >to the cookies.
> >
> >Once you get the session ID (using your method below) into 
> your servlet,
> >how do you tell the servlet to use it?  The only API I found 
> for that is
> >deprecated with no replacement.
> >
> >
> >  
> >
> >>>Thanks, Dave & Frank.
> >>>
> >>>I've followed both your suggestions.  The very first
> >>>lines in the servlet print out the various parameter, attributes, &
> >>>cookies.
> >>>Here's what I get:
> >>>      
> >>>
> >>Have you used a standard JS framework of some sort, or is 
> it in-house 
> >>code?  Testing with Firebug is, as has been stated, the way 
> >>to find out 
> >>what's being sent by your browser & therefore what the JS 
> code you're 
> >>using is actually doing.
> >>
> >>I concur with the chaps who've already posted - in that 
> your AJAX is 
> >>probably not sending the cookie data.
> >>
> >>
> >>You could manually attach the session id in your JS. We use the 
> >>following snippet to provide access to that data in JS, for 
> >>some parts 
> >>of one of our apps.
> >>
> >><script type="text/javascript">
> >>var Session = {
> >>   id : '${pageContext.session.id}',
> >>   user : '${pageContext.request.remoteUser}'
> >>}
> >></script>
> >>
> >>var url = path + ";jsessionid=" + Session.id + "?" + queryParams;
> >>
> >>
> >>p
> >>
> >>
> >>
> >>
> >>    
> >>
> >>>-- QUOTE --
> >>>******************
> >>>doPost entering
> >>>May 21 16:16:23: Session Attributes
> >>>
> >>>Session Attributes
> >>>May 21 16:16:23: Session isNew()= true
> >>>May 21 16:16:23: No attributes in this scope
> >>>
> >>>May 21 16:16:23: Request Attributes
> >>>
> >>>Request Attributes
> >>>May 21 16:16:23: No attributes in this scope
> >>>
> >>>May 21 16:16:23: Parameters
> >>>
> >>>Request Parameters
> >>>owner = 6
> >>>ajaxreq = getfora
> >>>type = 0
> >>>
> >>>
> >>>May 21 16:16:23: Cookies
> >>>May 21 16:16:23: 'JSESSIONID'='97E2CA20966390CCBC851738E71F3053'
> >>>May 21 16:16:23: Found 1 cookies
> >>>-- END QUOTE --
> >>>
> >>>As I said in my earlier post, the session being returned by 
> >>>      
> >>>
> >>getSession()
> >>    
> >>
> >>>is a new one;
> >>>when I call it like getSession(false) it return a null session.
> >>>Therefore, it contains
> >>>no attributes.  The parameters are, of course, exactly what 
> >>>      
> >>>
> >>I expected.
> >>    
> >>
> >>>As you can see,
> >>>there is the JSESSIONID cookie, but, for some reason, the 
> >>>      
> >>>
> >>servlet isn't
> >>    
> >>
> >>>using it, or it
> >>>is not valid.
> >>>
> >>>Again, according to Sun, everyone one of the API functions 
> >>>      
> >>>
> >>to manipulate
> >>    
> >>
> >>>session IDs are
> >>>deprecated, so I can't even kludge it up.  I have no idea 
> >>>      
> >>>
> >>if that is a
> >>    
> >>
> >>>valid session ID or
> >>>not.
> >>>
> >>>Also, I used Firebug to examine the XMLHttpRequest.  I'm 
> >>>      
> >>>
> >>not too sure
> >>    
> >>
> >>>what I'm looking for.
> >>>There was no reference to cookies, and all the stuff that I 
> >>>      
> >>>
> >>set was OK.
> >>    
> >>
> >>>Anyway, it seems to
> >>>be getting the cookie.
> >>>
> >>>Any ideas as to why the session wouldn't use this cookie, 
> >>>      
> >>>
> >>or why this
> >>    
> >>
> >>>cookie might be invalid?
> >>>In the process of this debugging, I have seen two 
> >>>      
> >>>
> >>JSESSIONIDs come over,
> >>    
> >>
> >>>one valid, one not.
> >>>
> >>>Thanks again for the help.
> >>>
> >>>
> >>>      
> >>>
> >>>>-----Original Message-----
> >>>>From: Frank W. Zammetti [mailto:fzlists@omnytex.com] 
> >>>>Sent: Monday, May 21, 2007 3:29 PM
> >>>>To: Tomcat Users List
> >>>>Cc: users@tomcat.apache.org; aladdin@csunv.com
> >>>>Subject: Re: Session IDs & XMLHttpRequests
> >>>>
> >>>>I can say with 100% certainty that a servlet invoked with 
> >>>>XMLHttpRequest
> >>>>**DOES** have the same access to server-side objects as a non-AJAX
> >>>>request.  I say this based on two applications in production 
> >>>>that do this
> >>>>all day long, one Struts-based, one not.  I also say it based 
> >>>>on a number
> >>>>of other applications, some using other frameworks, some 
> >>>>        
> >>>>
> >>using plain
> >>    
> >>
> >>>>servlets, all that do this as well, with no problems.
> >>>>
> >>>>Now, the two production apps, which are very much 
> >>>>        
> >>>>
> >>AJAX-based, not just
> >>    
> >>
> >>>>using it here and there, are running on Websphere, so that 
> >>>>        
> >>>>
> >>leaves the
> >>    
> >>
> >>>>possibility that there's something going on with Tomcat.  
> >>>>        
> >>>>
> >>However, I
> >>    
> >>
> >>>>generally develop under Tomcat, including most of those 
> >>>>        
> >>>>
> >>other apps I
> >>    
> >>
> >>>>mentioned, and never observed this problem.
> >>>>
> >>>>This isn't to say what your seeing isn't truly an issue, I 
> >>>>have no doubt
> >>>>it is... but, the only difference I can conceive of, based 
> >>>>        
> >>>>
> >>on all this
> >>    
> >>
> >>>>experience, between an AJAX request and a normal POST/GET, is 
> >>>>the session
> >>>>cookie not being passed in with the AJAX request.  I could 
> >>>>believe that
> >>>>might happen, and I could also believe it may be different 
> >>>>from browser to
> >>>>browser (don't misunderstand, I have no knowledge of this 
> >>>>being the case,
> >>>>but it wouldn't shock me).
> >>>>
> >>>>As another poster suggested, I would begin by monitoring 
> >>>>        
> >>>>
> >>the requests
> >>    
> >>
> >>>>going across in Firefox with Firebug, and perhaps 
> >>>>TamperData... you should
> >>>>be able to see every detail of the request and response 
> >>>>        
> >>>>
> >>with those...
> >>    
> >>
> >>>>compare an AJAX request with a plain form sumission or link 
> >>>>click and see
> >>>>if you notice any difference... I'd bet dollars to donuts 
> >>>>you'll find some
> >>>>header missing, or something along those lines.
> >>>>
> >>>>But, unless there's some peculiarity to your server setup or 
> >>>>environment,
> >>>>I can tell you for sure there's no fundamental difference to 
> >>>>the server
> >>>>between the two types of requests, and by extension, to the
> >>>>servlets/filters that execute to service the request.
> >>>>
> >>>>Frank
> >>>>
> >>>>-- 
> >>>>Frank W. Zammetti
> >>>>Founder and Chief Software Architect
> >>>>Omnytex Technologies
> >>>>http://www.omnytex.com
> >>>>AIM/Yahoo: fzammetti
> >>>>MSN: fzammetti@hotmail.com
> >>>>Author of "Practical Ajax Projects With Java Technology"
> >>>> (2006, Apress, ISBN 1-59059-695-1)
> >>>>and "JavaScript, DOM Scripting and Ajax Projects"
> >>>> (2007, Apress, ISBN 1-59059-816-4)
> >>>>Java Web Parts - http://javawebparts.sourceforge.net
> >>>> Supplying the wheel, so you don't have to reinvent it!
> >>>>
> >>>>On Mon, May 21, 2007 2:33 pm, 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
> >>>
> >>>
> >>>      
> >>>
> >>    
> >>
> >
> >---------------------------------------------------------------------
> >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