tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arieh Markel <>
Subject Re: About Form-Login-Config
Date Sat, 11 Nov 2000 01:41:41 GMT

> Mailing-List: contact; run by ezmlm
Craig, Costin,

thanks for your response.

> list-help: <>
> list-unsubscribe: <>
> list-post: <>
> Delivered-To: mailing list
> From: "Craig R. McClanahan" <>
> To:
> Subject: Re: About Form-Login-Config
> X-Spam-Rating: 1.6.2 0/1000/N
> Arieh Markel wrote:
> > I am reading the (2.3) spec and am realizing that I am not able to
> > share a login page with multiple contexts.
> >
> That's true (also true for servlet 2.2).
> >
> > In our (embedded) use of Tomcat, we have different contexts, but
> > we use a single login form/screen.
> >
> > When configuring the web.xml for those contexts, I realize that there is
> > no way to have a successful form-login-page without it belonging to the
> > same context.
> >
> > In our case, the login form is actually a servlet that belongs to the
> > default context.
> >
> > I was hoping to be able to point at that (default context /login)
> > servlet from the other contexts.
> >
> > One of the solutions could be to define a /login (the same) servlet
> > on all the various contexts.
> >
> > (I will mention that I am defining my contexts as 'trusted').
> > (Another note: I am using 3.2)
> >
> > If I do what mention in the last paragraph, I will end up with having
> > three different instances of the login servlet, right ?
> >
> Yes, assuming you have three contexts.
> But that isn't going to be the worst of it -- a user's identity does not
> propogate across web apps either, so a user that is using all three contexts
> will have to authenticate themselves to all three web apps.

I have resolved the authentication issue by sharing the session information
among the servlets of the different contexts (this was done by providing
some utility Java classes that are to be taken advantage by those
who develop our servlets - I admit that the solution is not generic, as
it implies that the servlets are aware of those utility classes).

There is always a single authentication, using the login servlet of the
default context.

On the non-default contexts, I opted to define a login page that performs
a redirection to the login servlet in the default context.

> >
> > ------
> >
> > An alternate approach could be to define 'login.html' files in those
> > contexts, and to have that file perform a Location redirect to the
> > default-context /login servlet.
> >
> Won't that cause the user to log in only to the default context?

Yes, but I don't care that it is the case, because the non-default context 
servlets are always reached from the login context.

The division of contexts is not so much to define segregated separate
web applications, as much as a cleaner way to separate between three
pieces of the application that we develop.

The first piece is the 'static' piece of our application, while the
second piece is a 'dynamic' piece, which is populated based on information
about objects discovered in the network.

(A third piece is a JavaHelp context - on which we put a single servlet,
that can access a JavaHelp document repository).

> >
> > ------
> >
> > I am wondering about the reasons that may have forced the definition
> > of a context-relative login-form as opposed to allowing a URL to be
> > specified.
> >
> The reasoning for this was the same as the reasoning for everything else in
> a web-app being context relative.  The whole idea is that a web application
> should be a stand alone entity, able to be deployed on *any* server that
> supports the required API levels, without external dependencies.
> The "escape valve" for cross-app authentication that the servlet spec
> provides is the notion of supporting "single sign on" (Servlet 2.2, section
> 11.6, and Servlet 2.3 PFD, section 12.6).  The basic idea is that a user
> authenticates himself or herself to the first app in which they try to
> access a protected page, and then this identity is remembered across all the
> other apps running in the same server.
> Unfortunately for your particular requirements :-(, none of the Tomcat 3.x
> versions support this feature -- although Tomcat 4.0 does.

I guess I must have implemented it in our application ;).

 Arieh Markel		                Sun Microsystems Inc.
 Network Storage                        500 Eldorado Blvd. MS UBRM11-194
 e-mail: arieh.markel@sun.COM           Broomfield, CO 80021
 Let's go Panthers !!!!                 Phone: (303) 272-8547 x78547
 (e-mail me with subject SEND PUBLIC KEY to get public key)

View raw message