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