RE: Session IDs XMLHttpRequests
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
RE: Session IDs XMLHttpRequests
I'll work on that today. -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 5:32 PM To: Tomcat Users List Subject: Re: Session IDs XMLHttpRequests On 5/21/07, Williams, Allen [EMAIL PROTECTED] wrote: As I said in my earlier post, the session being returned by getSession() is a new one; Can you create a simple test case WAR to demonstrate the failure? I have seen no such problems using Prototype, YUI, or DWR, which I'm currently incorporating into an app. To test your contention, I've printed the sessionId in a JSP page and made an XHR request via DWR to another simple JSP which logs the sessionId; it's the same, and that second controller page can access the same session attributes as the original page. So I have to suspect there's something odd about your setup -- the test case would be useful... FWIW, -- Hassan Schroeder [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]
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
RE: Session IDs XMLHttpRequests
Excellent! Thanks. I'm temporarily sidetracked for a couple of hours,
but then will go back to work on this.
Thanks, and Regards,
Allen Williams
[EMAIL PROTECTED]
Office: (321)309-7931
Mobile: (321)258-1272
FAX: (321)727-9607
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Monday, May 21, 2007 11:29 PM
To: Tomcat Users List
Subject: Re: Session IDs XMLHttpRequests
Let's start with this:
http://www.omnytex.com/test.zip
Just unzip into ${Tomcat}/webapps and try it... the first
time you click
the button you should see an alert saying testAttribute is null, the
second time it should say Test attribute has been set.
Now, do this
in Firefox and check each request that results from clicking
the button
with Firebug... specifically, expand the requests in the
Console view,
click the Headers tab, and look for JSESSIONID in the request headers
(that's how cookies are sent)... you should always see the
same value,
if you don't then something funky is going on. FYI, if you don't see
the requests, make sure you check the option in Firebug to record
XMLHttpRequest traffic (it may be off by default).
If you take this app and it works, modify it to the point where it
doesn't work and post it for us and we'll see if (a) we get the same
results, and (b) try to figure out why... if it doesn't work
as-is, then
there's definitely something wrong in your environment.
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!
Hassan Schroeder wrote:
On 5/21/07, Williams, Allen [EMAIL PROTECTED] wrote:
As I said in my earlier post, the session being returned
by getSession()
is a new one;
Can you create a simple test case WAR to demonstrate the failure?
I have seen no such problems using Prototype, YUI, or DWR, which
I'm currently incorporating into an app.
To test your contention, I've printed the sessionId in a
JSP page and
made an XHR request via DWR to another simple JSP which logs the
sessionId; it's the same, and that second controller page can access
the same session attributes as the original page.
So I have to suspect there's something odd about your setup -- the
test case would be useful...
FWIW,
-
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]
RE: Session IDs XMLHttpRequests
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
Re: Session IDs XMLHttpRequests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Williams, Allen wrote: Will it work with POST as well as GET? Although I guess I'll soon find out;-) It should work equally well with GET and POST. The browser should send cookies with every type of request (not just GET and POST). I strongly encourage you to make arrangements for non-cookie-using people. When you emit the HTML (and javascript) to make your XMLHttpRequest, try making the URL dynamic and running it through HttpServletResponse.encodeURL to add the jsessionid to the URL if necessary. This will make your application a little more friendly to those who either don't have cookies available (usually an IT policy in an office or something) or who choose to turn them off. I find this to be courteous to your users. Just my .02. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUvhK9CaO5/Lv0PARAtq0AKCfANKRxmb3ljBRiDLsb6gghTZHBgCcCdxW tUbl8cpKi44F53BrbHBmRjA= =zz// -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session IDs XMLHttpRequests
Yeah, I'm already sending some stuff over by URL anyway, but there seems to be some concern floating around the net regarding session hijacking if the session ID is readily available. However, although I wouldn't pretend to be an expert. Anyway, I took Christopher's advice, and deleted all the cookies, even restarted my browser (it's been running for several days), and did some testing. I now have two (2!) JSESSIONID's in my browser, as well as userid and password cookies, but on the server side, it says no cookies were sent. And, I finally found the Headers section under Net in Firebug. As near as I can decipher this, all my requests are sending a JSESSIONID cookie *except* the one for the XMLHttpRequest. The first time running after deleting all the cookies, that request doesn't have any cookies. Because a session gets created, from that point forward it has the session it created with it sent back in the request header, but, of course, that session doesn't have any of the attributes stored in it. Looking at these cookies with the WebDeveloper tools in Firefox, the difference is that the new one created during the XMLHttpRequest is associated with a / path, the other one (the real one) with /myAppName path. Is is possible the difference in these path associations has something to do with not finding the session? I do use a different URL mapping for this servlet because of a CheckUser problem I had way back that started this whole chain. Next step is to download Frank's http://www.omnytex.com/test.zip and get that to work (also, I see what you mean by Headers under Firebug Console, now, too- it is also repeated under Firebug Net). -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 10:04 AM To: Tomcat Users List Subject: Re: Session IDs XMLHttpRequests -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Williams, Allen wrote: Will it work with POST as well as GET? Although I guess I'll soon find out;-) It should work equally well with GET and POST. The browser should send cookies with every type of request (not just GET and POST). I strongly encourage you to make arrangements for non-cookie-using people. When you emit the HTML (and javascript) to make your XMLHttpRequest, try making the URL dynamic and running it through HttpServletResponse.encodeURL to add the jsessionid to the URL if necessary. This will make your application a little more friendly to those who either don't have cookies available (usually an IT policy in an office or something) or who choose to turn them off. I find this to be courteous to your users. Just my .02. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUvhK9CaO5/Lv0PARAtq0AKCfANKRxmb3ljBRiDLsb6gghTZHBgCcCdxW tUbl8cpKi44F53BrbHBmRjA= =zz// -END PGP SIGNATURE- - 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]
RE: Session IDs XMLHttpRequests
OK, I have FOUND the problem, and for the continued edification of the community will share my results, as well as ask one more question that hopefully some of you gurus can answer. Yes, it had to do with the path. When I went back and associated this servlet with a valid path used path but still without the CheckUser involved, updating through my mod_jk.conf, my web.xml for the mappings, and, of course, the script itself, it picked up the right session id and the world is good. Now, for the question: how is this ancillary information stored? When I look at the cookie in Firebug or print it out in the servlet, all I see is JSESSIONID=blah, blah, blah, but when I look at it in Web Developer, I see the path associated with it, the expiration date, and other info. Where is that stored, and can it be accessed (like the path, for instance) in a servlet or script? THANKS FOR ALL THE HELP!!! Thanks, and Regards, Yeah, I'm already sending some stuff over by URL anyway, but there seems to be some concern floating around the net regarding session hijacking if the session ID is readily available. However, although I wouldn't pretend to be an expert. Anyway, I took Christopher's advice, and deleted all the cookies, even restarted my browser (it's been running for several days), and did some testing. I now have two (2!) JSESSIONID's in my browser, as well as userid and password cookies, but on the server side, it says no cookies were sent. And, I finally found the Headers section under Net in Firebug. As near as I can decipher this, all my requests are sending a JSESSIONID cookie *except* the one for the XMLHttpRequest. The first time running after deleting all the cookies, that request doesn't have any cookies. Because a session gets created, from that point forward it has the session it created with it sent back in the request header, but, of course, that session doesn't have any of the attributes stored in it. Looking at these cookies with the WebDeveloper tools in Firefox, the difference is that the new one created during the XMLHttpRequest is associated with a / path, the other one (the real one) with /myAppName path. Is is possible the difference in these path associations has something to do with not finding the session? I do use a different URL mapping for this servlet because of a CheckUser problem I had way back that started this whole chain. Next step is to download Frank's http://www.omnytex.com/test.zip and get that to work (also, I see what you mean by Headers under Firebug Console, now, too- it is also repeated under Firebug Net). -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 10:04 AM To: Tomcat Users List Subject: Re: Session IDs XMLHttpRequests -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Williams, Allen wrote: Will it work with POST as well as GET? Although I guess I'll soon find out;-) It should work equally well with GET and POST. The browser should send cookies with every type of request (not just GET and POST). I strongly encourage you to make arrangements for non-cookie-using people. When you emit the HTML (and javascript) to make your XMLHttpRequest, try making the URL dynamic and running it through HttpServletResponse.encodeURL to add the jsessionid to the URL if necessary. This will make your application a little more friendly to those who either don't have cookies available (usually an IT policy in an office or something) or who choose to turn them off. I find this to be courteous to your users. Just my .02. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUvhK9CaO5/Lv0PARAtq0AKCfANKRxmb3ljBRiDLsb6gghTZHBgCcCdxW tUbl8cpKi44F53BrbHBmRjA= =zz// -END PGP SIGNATURE- - 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]
Re: Session IDs XMLHttpRequests [SOLVED]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Just adding [SOLVED] to the subject for the benefit of those searching the archives. To recap, the cookie path was wrong. - -chris Williams, Allen wrote: OK, I have FOUND the problem, and for the continued edification of the community will share my results, as well as ask one more question that hopefully some of you gurus can answer. Yes, it had to do with the path. When I went back and associated this servlet with a valid path used path but still without the CheckUser involved, updating through my mod_jk.conf, my web.xml for the mappings, and, of course, the script itself, it picked up the right session id and the world is good. Now, for the question: how is this ancillary information stored? When I look at the cookie in Firebug or print it out in the servlet, all I see is JSESSIONID=blah, blah, blah, but when I look at it in Web Developer, I see the path associated with it, the expiration date, and other info. Where is that stored, and can it be accessed (like the path, for instance) in a servlet or script? THANKS FOR ALL THE HELP!!! Thanks, and Regards, Yeah, I'm already sending some stuff over by URL anyway, but there seems to be some concern floating around the net regarding session hijacking if the session ID is readily available. However, although I wouldn't pretend to be an expert. Anyway, I took Christopher's advice, and deleted all the cookies, even restarted my browser (it's been running for several days), and did some testing. I now have two (2!) JSESSIONID's in my browser, as well as userid and password cookies, but on the server side, it says no cookies were sent. And, I finally found the Headers section under Net in Firebug. As near as I can decipher this, all my requests are sending a JSESSIONID cookie *except* the one for the XMLHttpRequest. The first time running after deleting all the cookies, that request doesn't have any cookies. Because a session gets created, from that point forward it has the session it created with it sent back in the request header, but, of course, that session doesn't have any of the attributes stored in it. Looking at these cookies with the WebDeveloper tools in Firefox, the difference is that the new one created during the XMLHttpRequest is associated with a / path, the other one (the real one) with /myAppName path. Is is possible the difference in these path associations has something to do with not finding the session? I do use a different URL mapping for this servlet because of a CheckUser problem I had way back that started this whole chain. Next step is to download Frank's http://www.omnytex.com/test.zip and get that to work (also, I see what you mean by Headers under Firebug Console, now, too- it is also repeated under Firebug Net). -Original Message- From: Christopher Schultz [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 22, 2007 10:04 AM To: Tomcat Users List Subject: Re: Session IDs XMLHttpRequests Allen, Williams, Allen wrote: Will it work with POST as well as GET? Although I guess I'll soon find out;-) It should work equally well with GET and POST. The browser should send cookies with every type of request (not just GET and POST). I strongly encourage you to make arrangements for non-cookie-using people. When you emit the HTML (and javascript) to make your XMLHttpRequest, try making the URL dynamic and running it through HttpServletResponse.encodeURL to add the jsessionid to the URL if necessary. This will make your application a little more friendly to those who either don't have cookies available (usually an IT policy in an office or something) or who choose to turn them off. I find this to be courteous to your users. Just my .02. -chris - 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] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU06d9CaO5/Lv0PARAgi+AKCfDp8K++T0kt22RgMwCFJRfFZ3sQCeNSXr GNnlB07KIACj4T7kF8ep6KY= =kwdF -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: Session IDs XMLHttpRequests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Williams, Allen wrote: Now, for the question: how is this ancillary information stored? The cookie contains all this information. When the cookie is transmitted to the browser, it contains all this information. Check it using an HTTP sniffer or your browser (Mozilla Firefox shows it all to you). When the cookie is sent back to the server in a request, this extra information is not included. For instance, the header sent to the server is simply: cookie: JSESSIONID=F53BFD60D943838CFA50EFDBCA27E825 When I look at the cookie in Firebug or print it out in the servlet, all I see is JSESSIONID=blah, blah, blah That is the content of the cookie. After the cookie is originally sent to the browser, the server doesn't know the details of the path, etc... that's the browser's problem. but when I look at it in Web Developer, I see the path associated with it, the expiration date, and other info. Firebug must just be showing you selected pieces of information. Web developer is showing you the browser's view of the world, which includes the extra metadata. Where is that stored, and can it be accessed (like the path, for instance) in a servlet or script? A script might be able to access it (because javascript runs on the client) but the server can only capture that information during the response that first created the cookie. In that case, you can use the Cookie objects in the response to sniff those values. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGU2Gm9CaO5/Lv0PARAqocAJwKQs1sVd9DdoHEHQ5cDTVEGkH43wCeOLEk dl5V9vazyYh+2Ucsaoy4zDk= =jQwS -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session IDs XMLHttpRequests
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, ... Firebug must just be showing you selected pieces of information. Web developer is showing you the browser's view of the world, which includes the extra metadata. Update your copy of Firebug if it's not clearly showing the contents of the cookie in the headers - my (most recent) version clearly indicates in the expected ';' separated, human readable format what the content, path and expiry date of the cookie is. p smime.p7s Description: S/MIME Cryptographic Signature
Re: Session IDs XMLHttpRequests
I'd say if there are differences, it's in the javascript of the client. Have you used any sort of monitoring tool to find out if XMLHttpRequest is sending the session cookie? Have you tried encoding the JSESSIONID in the XMLHttpRequest via javascript? --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]
RE: Session IDs XMLHttpRequests
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
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
Re: Session IDs XMLHttpRequests
Frank W. Zammetti wrote: 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. When using the Dojo toolkit with Tomcat 5.5, I noted that the session id was being sent transparently. This was critical for us because users login and so it's important that each request be associated with their respective sessions, and it worked like that out of the box. Again, just one experience that this can work under Tomcat just fine. David - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session IDs XMLHttpRequests
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: -- 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
Re: Session IDs XMLHttpRequests
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:
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
Re: Session IDs XMLHttpRequests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Allen, Williams, Allen wrote: 2. What is the difference in the servlet invocation between a regular URL invocation an XMLHttpInvocation? I'll be there isn't a difference, actually. I had a problem in the past where something went wrong and I ended up with two JSESSIONID cookies in my browser with the same host and path, but two different values. That was enough to confuse things such that some requests worked (those that went directly to Tomcat) and others didn't (I think it was some that had been routed through Cocoon maybe?). I had to delete both cookies and then everything got straightened out. This was further complicated by the fact that Firefox refuses to accept cookies for a particular site after you delete them unless you then remove the never allow rule it sets. Anyhow, I thought this might help: try deleting the cookies from your browser and starting fresh. It might help. 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). That's right: you could have kludged it up. In fact, it turns out that the only use for those deprecated portions of the API are for kludgey messes. You can achieve most legitimate uses of those deprecated methods by using a SessionListener or whatever and then maintaining your own registry of sessions. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUiKg9CaO5/Lv0PARAis4AJ9YMlDAtYO/xYA1w5+PYujrfOprKwCfcE0A Bns3j0VcZZNWAAscmdX/KRU= =6ME3 -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
