Bartsch Axel wrote:
> Hi,
>
> I am using TOMCAT 3.3 together with Apache (mode JK).
>
> I have defined 2 servlet contexts (two directories below webapps) with one TOMCAT
>instance.
>
> Now a user logs in at a servlet within context1 and a HttpSession object is created.
> Then this request is forwarded to a servlet within context2 or the user accesses
>this servlet (within context2) directly (or via a HREF on a HTML page).
>
> The servlet within context2 then cannot find the HttpSession and rejects the access.
>
> How can I have the servlet within context2 find the HttpSession (created within
>context1)?
>
> Axel Lannion/France
> [...]
Hi :-) I am not sure, I guess now you have to make a "custom HttpSession" for
across-context/across-container session. please read the following emails:
On Fri, 11 May 2001, Antony Bowesman wrote:
> Hi,
>
> Is it correct behaviour for Tomcat to create a different session when a
> call is made to request.getSession(true) if the context is different.
>
Yes. That's required by the servlet spec. It also makes sense when you
think about the class loading aspect: each web application has its own
class loader that provides access (for that app) to the contents of
WEB-INF/classes and WEB-INF/lib. If you create a session attribute based
on one of these classes, that class itself cannot be loaded from any other
web app.
> I ask because I have a realm implementation that caches stuff in session
> relating to authentication. I have two contexts in server.xml and each
> context defines its own JAAS authentication parameters in web.xml. My
> realm can then determine if a user is authenticated in a particular
> context. To do this I am using session in the realm and noticed that
> each context has a different session.
>
You might want to look at how Tomcat 4.0 addresses the "single sign
on" feature of the servlet spec, which requires user authentication to be
global across the web apps in a virtual host (even though the
sessions are unique). It's done by maintaining a separate cookie, and a
separate collection of available "authentications", that intervenes before
the usual per-web-app authentication takes place. The class you want to
look at is org.apache.catalina.authenticator.SingleSignOn -- plus you will
want to examine the other classes in the same package to see how the
interactions work.
> Can someone please explain how Tomcat determines if a session should be
> created when getSession(true) is called.
As above, sessions are required to be per-webapp. You'll need to use some
different mechanism to cache stuff across webapps.
> Rgds
> Antony
> --
> Antony Bowesman
> Teamware Group
> [EMAIL PROTECTED]
> tel: +358 9 5128 2562
> fax: +358 9 5128 2705
>
Craig McClanahan
****************************************************************
Sessions do indeed belong to webapps. This is mandated by the servlet
specification, and Tomcat enforces the restriction. (See the Catalina
configuration documentation on "Single Sign On" for information on how to
configure Tomcat 4.0 so that you only have to sign on once, even though
the sessions for different web apps are still separate.)
Tomcat 4.0 attempts to save and restore sessions across restarts -- either
because of automatic reloading or because of a manual shutdown and
restart. As long as all of your session attributes implement
java.io.Serializable, the attributes will be saved and restorted as well.
NOTE: Various versions of 4.0 (including beta 1) have had problems with
this, which have been fixed in more recent versions. I would suggest
downloading a recent nightly build, or waiting for Tomcat 4.0 Beta 4 which
is scheduled to be released tonight.
Craig McClanahan
Bo
May.22, 2001
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
