tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <ar...@exoffice.com>
Subject Re: login-config handling (was Re: Help with Interceptors)
Date Fri, 11 Feb 2000 00:15:53 GMT
> I am willing to help get this implemented.

Excellent.

> Inspection of the spec (2.2) indicates that the form-login-page is
> the
> 
>         "location in the web app where the page that can be used for
>         login can be found"
> 
> 
> This appears not to address my need, since I would like to be able to have
> the same login page for multiple web apps.

Actually I think that the form is specific for a context. Since you
specify it in the deployment descriptor, each context will use a
different form, and different session.

What you want to do is be able to carry the login from one context to
another. Once you logged into one context, you are automatically logged
on in the other. Have no clue how to make it happen, but I think that's
how it should work.


> --
> 
> With regards to helping in the implementation, I need some guidance as to
> the context on which the checking of prior access to the login-page has
> been done.
> 
> What are the ideas of implementing this ?

In my understanding you need to somehow track the client to do that, so
that would map to the session. Before a new session is created (which
implies new user), you need to authenticate. Then you can use the cookie
(or session itself) to track the user.

Keep in mind that you might get two different sessions for two different
contexts.


> --
> 
> Some of what I have in mind deal with checking HttpSession information.
> 
> In our implementation, I wanted to be able to handle the case of users
> that do not accept cookies. I maintain a session-id keyed- Hashtable that
> maintains valid sessions.

You will need to embedd the session identifier into the URLs to carry it
from one request to another.


> --
> 
> So in general, the default login page needs to be set whenever a URL access
> that does not find a session (or a cookie) is detected.

Yes, when a session is not found, regardless of whether it's cookie, URL
embedded, SSL, etc.


> --
> 
> With regards to the handling of the login information, I presume that the
> code to support that needs to be in WebXmlInterceptor, right ?

Have no clue :-)


> Along the lines of adding a:
> 
>         private void processLoginConfig ()
> 
> method.
> 
> The second part, as I see from the code could be in the context of
> the ServletWrapper invocation and the subsequent RequestImpl setting of
> the session.

Probably in ServletWrapper. Instead of executing the requested Servlet
it will execute the Login servlet. The question that now arises is, how
do you tell the Login Servlet to jump into the requested Servlet when
the form is completed.

That is, if my request was for ServletX, I get into the login Servlet,
login, and if I'm successful it redirects me to ServletX.


> --
> 
> Am I off in my assumption that login-page verification equates session
> establishment ?

Probably not. The session will be created whether or not you managed to
login. But you shouldn't be able to call any other Servlet until you
pass authentication.


Somehow there should be a way for the Servlet to either authenticate you
as 'anyone' if you don't pass the login test, or refuse to let you in
until you pass it.

There should also be a way to get into the login Serlvet and
reauthenticate.

arkin

> 
> (That is at least how we treat it in our application).
> 
> --
> Arieh
> --
>  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)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Mime
View raw message