Re: Session IDs & XMLHttpRequests

[Pid]

Williams, Allen wrote:

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:

<script type="text/javascript">
var Session = {
  id : '${pageContext.session.id}',
  user : '${pageContext.request.remoteUser}'
}
</script>

var url = path + ";jsessionid=" + Session.id + "?" + queryParams;


p

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.

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


**DOES** have the same access to server-side objects as a non-AJAX

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.


it is... but, the only difference I can conceive of, based on all this

but it wouldn't shock me).

As another poster suggested, I would begin by monitoring the requests

be able to see every detail of the request and response with those...

header missing, or something along those lines.


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 can say with 100% certainty that a servlet invoked with XMLHttpRequest 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 This isn't to say what your seeing isn't truly an issue, I have no doubt 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, going across in Firefox with Firebug, and perhaps TamperData... you should 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 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

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]

smime.p7s
Description: S/MIME Cryptographic Signature