> 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: [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]
