Nope.  I have a JSP with only 26 lines (started with about 7 lines but I've
been 
adding more information).
What I'm finding now is that if I shut down my browser and restart it then
the 
result of HttpSession.getId is a new random string.  On the first refresh,
that 
id is also put in the browser cookie as "JSESSIONID".  Some other user
connecting 
from a browser running on a different machine can (not always) then "steal"
my session 
and rewrite HttpSession.getId.  Subsequently the other browser has getId and

JSESSIONID consistent with the new id, and my browser has getId and
JSESSIONID 
inconsistent(!!!) with the getId equal to the new id and JSESSIONID equal to
the old id.

Here's the JSP:

  <html>
  <head>
  <title>Huw's snoop page</title>
  </head>
  <body>

  <%HttpSession ss = request.getSession(true); %>
  SessionId: <%= ss.getId() %><br>
  IsNew: <%= ss.isNew() ? "true" : "false" %><br>
  <%Integer i = (Integer)ss.getAttribute("fred");
    if (i == null) 
      i = new Integer(0); 
    else 
      i = new Integer(i.intValue()+1);
    ss.setAttribute("fred", i); 
  %>
  Count: <%= i.toString() %><br>
  <%Cookie[] cookie = request.getCookies(); %>
  Cookies:<br>
  <%for (int j=0; j<cookie.length; j++) { %>
  <%=cookie[j].getName()%>&nbsp<%=cookie[j].getValue()%><br>
  <%}%>

  </body>
  </html>


Thanks,
Huw


>  -----Original Message-----
> From:         [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 02 May 2001 17:13
> To:   '[EMAIL PROTECTED]'
> Subject:      RE: Problem with session tracking.  Please help
> 
> I have seen a problem with sessions in the past due to bad 
> program design.
> Make sure that your servlets have no members. If so, they 
> would share them between all users.
> 
> Try to make a simple example first to make sure that you can 
> maintain session state.
> 
> Regards, Jan Kester
> 
        > -----Original Message-----
        > From: William Kaufman [SMTP:[EMAIL PROTECTED]]
        > Sent: woensdag 2 mei 2001 17:10
        > To:   '[EMAIL PROTECTED]'
        > Subject:      RE: Problem with session tracking.  Please help
        > 
        > Are both the servers running on the same host?  This sounds 
        > like a problem
        > I've run into: since cookies are identified by host, all cookies
named
        > "JSESSIONID" from the same host are considered the same cookie.  
        > 
        > In my case, the servlets are running on different ports on 
        > the same machine.
        > I can't see anything in the cookie spec (RFC 2109) which lets 
        > you segregate
        > cookies by port, so I'm out of luck (and maybe you are, too, 
        > if that's what
        > you're doing).
        > 
        > If this isn't your case, try seeing what Tomcat is putting in 
        > the JSESSIONID
        > cookie.  A cheezy way to do this would be to use IE: in the
security
        > settings for your host, change the cookie settings to 
        > "Prompt"; then, when
        > hitting your site, you'll get an alert from which you can see 
        > the cookie
        > info.
        > 
        > 
        >                                                             --
Bill K.
        > 
        > 
        > > -----Original Message-----
        > > From: Roberts Huw [mailto:[EMAIL PROTECTED]]
        > > Sent: Wednesday, May 02, 2001 7:24 AM
        > > To: '[EMAIL PROTECTED]'
        > > Subject: RE: Problem with session tracking. Please help
        > > 
        > > 
        > > 
        > > 
        > > > -----Original Message-----
        > > > From: William Kaufman [mailto:[EMAIL PROTECTED]]
        > > > Sent: 02 May 2001 15:02
        > > > To: '[EMAIL PROTECTED]'
        > > > Subject: RE: Problem with session tracking. Please help
        > > > 
        > > > 
        > > > 1) Does your browser have cookies enabled?  If not, you need 
        > > > to rewrite all
        > > > your URLs, using HttpServletResponse.encode[Redirect]URL().
        > > > 
        > > 
        > > Yes it does have cookies enabled.  Supposing I decide to use the
        > > above code, should I just stick it at the top of my JSP?
        > > 
        > > > 2) Are you defining a cookie or URL parameter names 
        > > > "jsessionid"?  That one
        > > > is used by Tomcat to keep track of the session, and shouldn't 
        > > > be set by the
        > > > servlet.
        > > > 
        > > 
        > > I'm not doing either of these things.
        > > 
        > > > 3) Does HttpSession.getId() keep returning new IDs, and 
        > > > HttpSession.isNew()
        > > > keep returning "true" on each call to your servlet?
        > > > 
        > > 
        > > No.  What seems to be happening is that a browser will "steal"
        > > a previously existing session while it is still owned by another
        > > browser.  
        > > 
        > > I have two machines "A" and "B".  "A" looks at the page and gets
        > > a session id (e.g.)"A1" and isNew() returns true.  "A" then 
        > refreshes 
        > > the page a number of times.  session id is still "A1" and
isNew()
        > > returns false.  Everything is wonderful.  Browser "B" looks 
        > > at the page
        > > and gets a session id "B1".  isNew() returns true, but the
objects 
        > > attached to it are the objects that were
        > > associated with session "A1".  If "A" then does a refresh then
the
        > > session id comes back as "B1" and the objects are the same
objects.
        > > From this point on the two browsers share the session and
session id
        > > and the objects attached to the session until the session is
timed 
        > > out by tomcat.
        > > 
        > > > As for documentation, the servlet spec goes into this 
        > > stuff.  You can
        > > > download it at,
        > > > 
        > > >     http://java.sun.com/products/servlet/download.html
        > > > 
        > > > 
        > > >                                                             
        > > -- Bill K.
        > > > 
        > > 
        > > Thanks Bill.
        > > 
        > > > 
        > > > > -----Original Message-----
        > > > > From: Roberts Huw [mailto:[EMAIL PROTECTED]]
        > > > > Sent: Wednesday, May 02, 2001 3:21 AM
        > > > > To: '[EMAIL PROTECTED]'
        > > > > Subject: Problem with session tracking. Please help
        > > > > 
        > > > > 
        > > > > Hi All,
        > > > > 
        > > > > We're having a problem with session tracking.
        > > > > We are using tomcat pretty much "out of the box", without 
        > > > integrating
        > > > > with apache or anything like that.
        > > > > We are attaching an attribute to the session which we want 
        > > > (reasonably
        > > > > enough) to be "per session".
        > > > > We are then sending requests for information to tomcat 
        > > from several
        > > > > different client machines (sometimes logged on as the same 
        > > > > user, sometimes
        > > > > as different users, sometimes using Netscape, sometimes
using 
        > > > > IE).  All
        > > > > machines are running Windows NT4.0.
        > > > > 
        > > > > What we are finding is that the Session objects are being 
        > > > > indiscriminately
        > > > > associated with the servlets.  We are getting the right 
        > number of
        > > > > session attributes created, but when we refresh the page we 
        > > > find that
        > > > > the new request is associated with the wrong session.
        > > > > 
        > > > > Help?  Is there anything obvious we are missing?  Is there a

        > > > > document on
        > > > > how the session management works in tomcat?
        > > > > 
        > > > > We are using tomcat-3_3-m1
        > > > > 
        > > > > Thanks a lot,
        > > > > Huw
        > > > > 
        > > > >
**************************************************************
        > > > > **********
        > > > > The information in this email is confidential and is 
        > > intended solely
        > > > > for the addressee(s).
        > > > > Access to this email by anyone else is unauthorised. If 
        > > you are not
        > > > > an intended recipient, you must not read, use or disseminate
the
        > > > > information contained in the email.
        > > > > Any views expressed in this message are those of the
individual
        > > > > sender, except where the sender specifically states them to
be
        > > > > the views of Capco.
        > > > > 
        > > > > http://www.capco.com
        > > > >
**************************************************************
        > > > > *********
        > > > > 
        > > > 
        > > 
        > > **************************************************************
        > > **********
        > > The information in this email is confidential and is intended
solely
        > > for the addressee(s).
        > > Access to this email by anyone else is unauthorised. If you are
not
        > > an intended recipient, you must not read, use or disseminate the
        > > information contained in the email.
        > > Any views expressed in this message are those of the individual
        > > sender, except where the sender specifically states them to be
        > > the views of Capco.
        > > 
        > > http://www.capco.com
        > > **************************************************************
        > > *********
        > > 

************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***********************************************************************

Reply via email to