Craig,
Thanks for all that!!
We do handle individual user sessions (as opposed to browser sessions) so
that each is a distinct login and logout of the web apps.
Dan
> ----------
> From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, June 08, 1999 11:40 AM
> To: Kirkdorffer, Daniel
> Cc: [EMAIL PROTECTED]
> Subject: Re: LIFESPAN=session and getSession()
>
> "Kirkdorffer, Daniel" wrote:
>
> > Craig,
> >
> > Ok, let me get this straight: are you saying the problem is resolved
> with
> > 2.1 compliant engines?
> >
> > When I create a new session with WebSphere it creates a cookie that
> lasts
> > the life of my browser, or until a session timeout. The cookie is
> called
> > "sessionid". Certainly the session is maintained at a server level.
> What
> > I said to David before about web apps from different web servers causing
> > problems is false. The session id is a client to web server handshake,
> so
> > David's invalidates wouldn't affect my web apps. However, multiple web
> apps
> > from the same web server would affect each other.
> >
> > My apologies for the confusion.
> >
> > I can't find any good reading on the issue for 2.1 compliant engines.
> >
> > Dan
> >
>
> I don't know which version of Websphere supports which version of the
> servlet
> API -- but the comments below deal ONLY with 2.1-compliant engines. In
> 2.0-compliant engines, you could not rely on consistent implementations on
> session management.
>
> The Servlet API Specification (Version 2.1a) is the starting point for
> reading. It's available at JavasSoft's web site:
>
> http://java.sun.com/products/servlet/index.html
>
> The recently released JavaServer Pages (JSP) Specification (Version 1.0)
> is
> based on the 2.1 servlet API, and includes some important "clarifications"
> to
> the servlet API spec. These clarifications do not change the binary API
> in any
> way, but they document the common behaviors that servlet engines are
> expected
> to provide on many issues that weren't clear in the servlet spec. See
> especially Appendix B.
>
> http://java.sun.com/products/jsp/index.html
>
> The relationship between a session and a ServletContext is not very clear
> from
> the servlet API spec, so this was one of the clearifications. See section
> B.5
> of the JSP spec. The language is still a little fuzzy, but the reasoning
> behind all of this is clear:
>
> * A ServletContext is unique to a particular
> virtual host (from the servlet spec).
>
> * A ServletContext (servlet spec) is the same as
> an "application" (from the JSP spec).
>
> * Applications need to share state information
> among their components, and can do so in
> several ways (matching the "scope" concept
> in the JSP spec):
> * Page - Not shared
> * Request - Shared by storing attributes
> in a ServletRequest
> * Session - Shared by storing attributes
> in an HttpSession
> * Application - Shared by storing attributes
> in a ServletContext.
>
> * As a side effect: if you want to share stuff
> betweeen applications on the same virtual host,
> you have to use mechanisms outside the specs.
>
> * Applications need to be sandboxed from each
> other, so that they don't interfere. If sessions
> were shared across applications, that would give
> application A the chance to read (and modify)
> the stored state information for application B.
> This would be a "Bad Thing".
>
> * Discussions on the "Servlet Experts" Mailing
> List (consisting of many implementors of servlet
> engines) has clarified that sessions are unique
> to a context (==application), not to a host,
> in a compliant 2.1 servlet engine. This will
> be more clear in future versions of the servlet
> API specs.
>
> So what does this mean at the implementation level? Let's assume you are
> logged in to sessions on several applications at the same time (from the
> same
> browser), and you are using cookies for session management.
>
> * Apps on two different servers are no problem,
> even if the name of the cookie used for session
> identification is the same. This is because the
> browser sends back a cookie only to the host it
> came from, and only to URI paths that match
> the "path" that was set for this cookie (which
> should be the path to the ServletContext this
> app is running in).
>
> * Apps on the same server are no problem if
> different cookie names are used for each app,
> because the servlet engine will not recognize
> the session ID cookie for the "other" app, even
> if the browser sends it. Your servlet engine
> should have a way to configure the name of
> the session ID cookie for each context.
>
> * Apps on the same server are no problem, even
> if the same cookie name is used for each context,
> as long as all of the following are true:
>
> * The servlet engine includes a "path" on
> the session id cookie it sends. This
> path is unique per ServletContext.
>
> * The browser correctly manages its
> cookie database so that it knows the
> following two cookies are different:
>
> Name=sessionid Domain=www.mycompany.com Path=/firstapp Value=...
>
> Name=sessionid Domain=www.mycompany.com Path=/secondapp Value=...
>
> I have heard that some early browsers do not deal with this correctly, but
> it
> is supposed to work with the newer ones. Using different cookie names (if
> this
> is supported by your servlet engine) should always work.
>
> Moral of the story: On a 2.1-compliant servlet engine, it should be no
> problem
> for an individual user to be participating in sessions on multiple
> applications
> simultaneously, on the same or different hosts. You can (and should)
> invalidate individual sessions when the user logs out of one of these
> apps, to
> avoid the next person in from the same browser getting into that
> application
> without logging on (this is just like the old timeshare days -- if you
> don't
> log out of your terminal when you're done, the next person in can use your
> account).
>
> Hope this helps clarify things!
>
> Craig
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
