Will it work with POST as well as GET? Although I guess I'll soon find out;-)
Thanks, and Regards, ________________________ Allen Williams [EMAIL PROTECTED] Office: (321)309-7931 Mobile: (321)258-1272 FAX: (321)727-9607 > -----Original Message----- > From: David Smith [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > >>>>Sent: Monday, May 21, 2007 3:29 PM > >>>>To: Tomcat Users List > >>>>Cc: users@tomcat.apache.org; [EMAIL PROTECTED] > >>>>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: [EMAIL PROTECTED] > >>>>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: [EMAIL PROTECTED] > >>>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>------------------------------------------------------------ > --------- > >> > >> > >>>>To start a new topic, e-mail: users@tomcat.apache.org > >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>------------------------------------------------------------ > --------- > >> > >> > >>>To start a new topic, e-mail: users@tomcat.apache.org > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >> > >> > > > >--------------------------------------------------------------------- > >To start a new topic, e-mail: users@tomcat.apache.org > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
