> No, you're not getting what sessions are I think. It doesn't matter if you
store the jsessionid in a perstitant cookie, when you
> pass that id back to the appserver, it is just going to create a new
session for you because the session has expired.
>
doesn't the jsession id relate a particular user to a session? so, one
jsessionid per session? My problem. i think, is that the same jsessionid is
not being used across multiple browser windows so, the open session on the
app server is not being associated with the current user... is this totally
off base?
> 2. Make session expiry 24 hours.
>
> Option 1 results in a fairly insecure site, option 2 may result in massive
memory usage under heavy loads.
This is a site that will be used by a total of 4 people and probably never
more than one at a time :) no problem on memory usage...
I tryed this... so sessions never expire... just to see if this works...
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
no good... same behavior... session does not span multiple browser windows..
>
>
> > ----- Original Message -----
> > From: "Gareth Coltman" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, September 04, 2001 8:54 AM
> > Subject: RE: security
> >
> >
> > > >
> > > > It looks like login is using soft... is there a way to switch
> > > > it to hard?
> > > >
> > >
> > > Well, no I wouldn't think so. Session cookies are stored by
> > the browser in
> > memory. When the browser closes, the session dies. The
> > > session cookie (ie the id) is valid only for the lifetime
> > of the session -
> > this is why it is not persisted. The volitile nature of
> > > sessions (ie they expire) makes it a little pointless to
> > store the cookie
> > on disk.
> > >
> > > Hard cookies are not for session tracking, they are used to
> > store things
> > like usernames, preferences etc.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
